Re: Finding HHello jennie,elp

Hello,

(Chair hat off). Context sensitive help is incredibly important but I
believe outside the scope of this SC. I am concerned that adding it in at
this point will keep us from moving this important SC on non-context
sensitive help forward.  It seems like we should work through a separate SC
for context sensitive help through the next round of process (either WCAG
2.3 or 3.0). Based on the excellent points about search being difficult for
smaller websites, I think we should go back to the earlier SC wording and
then add in more details about what would make good self-help in the
understanding document. We could then include the benefits of search in
there.

Rachael

On Tue, Apr 14, 2020 at 11:42 AM Niemann, Gundula <gundula.niemann@sap.com>
wrote:

> Hello Jennie,
>
>
>
> of course some background helps. Thank you for providing.
>
> Nevertheless, context help according to my experience with end-users and
> with testing is the one most often needed and very often missed.
>
> You stated something is needed beyond that.
>
> I understand that context help in your point of view is needed (from your
> wording I conclude you take it as a prerequisite), yet it does not suffice.
>
>
>
> What about requesting both then?
>
>
>
> So the suggestion for the SC is:
>
>
>
> For single page apps or any set of web pages
> <https://www.w3.org/TR/WCAG21/#dfn-set-of-web-pages> with blocks of
> content that are repeated on multiple web pages
> <https://www.w3.org/TR/WCAG21/#dfn-web-page-s>, a self-help option
> including a context help is available and at least one of the following
> is included or linked in a consistent location:
>
> · Human contact details
>
> · Human contact mechanism
>
> · A fully automated chatbot that can:
>
> o recognize misspelled words,
>
> o provide human contact details if the chatbot is unable to provide a
> satisfactory response after 3 attempts,
>
> o be dismissed with a single interaction, and recalled using a link or
> button.
>
>
>
> Except for archival unsupported content which is clearly labeled as such,
> or where finding help would invalidate the activity.
>
>
>
> (I colored the background of the main change.)
>
>
>
> Best regards,
>
> Gundula
>
>
>
> *From:* Delisi, Jennie (MNIT) <jennie.delisi@state.mn.us>
> *Sent:* Dienstag, 14. April 2020 17:26
> *To:* Niemann, Gundula <gundula.niemann@sap.com>; Alastair Campbell <
> acampbell@nomensa.com>; Rachael Bradley Montgomery <
> rachael@accessiblecommunity.org>; Keim, Oliver <oliver.keim@sap.com>;
> WCAG <w3c-wai-gl@w3.org>
> *Subject:* RE: Finding Help
>
>
>
> Maybe some context would be helpful.
>
>
>
> Contextual help is not the intent of this proposed success criteria. This
> is intended to support beyond contextual help. And, there should still be
> language that indicates contextual help does not satisfy the success
> criteria.
>
>
>
> What a website does is also not the intent of the help. Originally, the
> goal was to support those using a website to complete a task on the site.
> And, that have trouble finding the help available – easily. The intent is a
> scenario like:
>
>    1. I am on a website, trying to complete a task. I encounter
>    difficulty.
>    2. Finding the help available, preferably a person, is easy to locate.
>    Easy: meaning in the same location on every page.
>    3. When a person is not available, knowing what help is available
>    (such as an FAQ) helps me quickly determine if there is something that can
>    help me beyond the contextual help on that page.
>
>
>
> Please let me know if this helps clarify the intent.
>
> Jennie
>
>
>
> *Jennie Delisi, MA, CPWA*
>
> Accessibility Analyst | Office of Accessibility
>
> *Minnesota IT Services* |* Partners in Performance*
>
> 658 Cedar Street
>
> St. Paul, MN 55155
>
> O: 651-201-1135
>
> *Information Technology for Minnesota Government* | mn.gov/mnit
>
> [image: Minnesota IT Services Logo]
>
> [image: Facebook logo] <https://www.facebook.com/MN.ITServices>[image:
> LinkedIn logo] <https://www.linkedin.com/company/mn-it-services>[image:
> Twitter logo] <https://twitter.com/mnit_services>
>
>
>
> *From:* Niemann, Gundula <gundula.niemann@sap.com>
> *Sent:* Tuesday, April 14, 2020 10:15 AM
> *To:* Alastair Campbell <acampbell@nomensa.com>; Rachael Bradley
> Montgomery <rachael@accessiblecommunity.org>; Keim, Oliver <
> oliver.keim@sap.com>; WCAG <w3c-wai-gl@w3.org>; Delisi, Jennie (MNIT) <
> jennie.delisi@state.mn.us>
> *Subject:* RE: Finding Help
>
>
>
> *This message may be from an external email source.*
>
> Do not select links or open attachments unless verified. Report all
> suspicious emails to Minnesota IT Services Security Operations Center.
>
>
> ------------------------------
>
> Hello Alastair,
>
>
>
> maybe we can use the example to illustrate what I would like to see as
> online help (specifically context help).
>
>
>
> I opened that app, and I have no clue what it does. No explanation, no
> input help.
>
> No clue.
>
> Even after interaction (“try one of these” – I chose one) I have no clue
> what this app does.
>
> My colleague found out what it does: It compresses image files.
>
>
>
> So what it needs (let’s imagine it was accessible and well-designed):
>
>    - An explanation what it does and which options it provides. Amount: a
>    few lines, maybe half a page.
>    - Context help that answers the questions (with the respective UI
>    element):
>
>
>    - How can I zoom the image with keyboard?
>       - How can I pan with keyboard?
>       - …
>
> Amount: some words or a sentence each
>
>
>
> Our main concern is that context help should be provided.
>
> Most user questions arise around how interaction is done for specific UI
> elements, and here specifically with keyboard.
>
>
>
> The help should be adequate for the complexity of the application / web
> site.
>
> A small app might need a one-pager next to it and some context help.
>
> A large business application might need a handbook which explains
> interaction as well as the application, next to context help inside the
> application itself.
>
> The handbook for the large application is rarely missing.
>
> The context help inside the application is often missing, independently of
> the size of application.
>
>
>
> I agree a search mechanism is not adequate in all cases and thus might be
> recommended in case of complex sites with a large help, but a search
> mechanism should not be requested for all applications / web sites.
>
>
>
> Best regards,
>
> Gundula
>
>
>
>
>
> *From:* Alastair Campbell <acampbell@nomensa.com>
> *Sent:* Dienstag, 14. April 2020 15:35
> *To:* Niemann, Gundula <gundula.niemann@sap.com>; Rachael Bradley
> Montgomery <rachael@accessiblecommunity.org>; Keim, Oliver <
> oliver.keim@sap.com>; WCAG <w3c-wai-gl@w3.org>; Delisi, Jennie (MNIT) <
> jennie.delisi@state.mn.us>
> *Subject:* RE: Finding Help
>
>
>
> Hi Gundual,
>
>
>
> > I do object to accepting an FAQ to fulfill the requirement. An FAQ is a
> nice-to-have, but it does not suffice the intention of the SC: to ensure
> available help for the end-user.
>
>
>
> A lot of the smaller organizations (/people) I work with would not be able
> to provide a full help section, especially with a search mechanism.
>
>
>
> There are small websites and single page apps that do one thing, e.g.
> https://squoosh.app/
> <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsquoosh.app%2F&data=02%7C01%7Cjennie.delisi%40state.mn.us%7C81622fa8a5e3490cb44e08d7e086a1c7%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C637224741156177151&sdata=JMtvDFxsAaREzJOs4XOsTIwLR%2BeX0emkHxjkbT6Vnuc%3D&reserved=0>
> .
>
> (Just an example that came to mind, no personal connection and I’m not
> saying it is paragon of accessibility.)
>
>
>
> Including a help section bigger than the rest of the website is an odd
> requirement to make.
>
>
>
> Kind regards,
>
>
>
> -Alastair
>


-- 
Rachael Montgomery, PhD
Director, Accessible Community
rachael@accessiblecommunity.org

"I will paint this day with laughter;
I will frame this night in song."
 - Og Mandino