search

w3c / matf

Guidance from the Mobile Accessibility Task Force (MATF)
https://w3c.github.io/matf/
Other
8 stars 2 forks source link

Success Criterion 3.2.6 - Consistent Help - Level A #43

Open JJdeGroot opened 3 months ago

JJdeGroot commented 3 months ago

WCAG2ICT guidance: https://www.w3.org/TR/wcag2ict-22/#consistent-help

Share your thoughts for applying to mobile apps as a comment below.

jamieherrera commented 1 month ago

This seems like it could almost live as written in WCAG with the change from "page" to "screen" and "set of web pages" to "set of app screens".

Hybrid content could be included in this as far as hybrid (web) content surrounding a component that is otherwise part of the app.

Keanem6 commented 4 weeks ago

Agree with Jamie that this can be applied pretty much as written with variations on "page" and "set of web pages" to what ever the definition of 'views' is given. Would also need to update Note 2 and remove reference to CSS break-points.

JJdeGroot commented 4 weeks ago

Decision of two month ago:

A proposal not to add 10.3.2.6 and 11.3.2.6 to EN 301 549 and to therefore mark the clauses as Void, was agreed at the 7th August STF614 Meeting.

Some considerations:

Regarding 3.2.6, the following options need to be considered:

  • 3.2.6 is not applicable to software in any meaningful way;
  • 3.2.6 should not be included when revising EN 301 549 to align with WCAG 2.2 because it relates to web pages within a set of web pages;
  • there should be an attempt to find a way of applying 3.2.6 and the previously excluded SCs to parts of a single software program (which would be of significant benefit).

Given this rewrite and the strong reliance on "set of", I don't think that 3.2.6 can apply to individual software (or documents). So I suggest that 10.3.2.6 and 11.3.2.6 become "void" entries in EN 301 549.

This SC does not seem to relate to open/closed functionality. But for hardware with closed functionality for screen reading, for example, help might be called on after invoking a physical control. A possible interpretation of this criterion, in such circumstances, could be to make sure that the help feature is always possible to reach using that same hardware control. But is this a reasonable thing to require? Any such recommendation should be grounded in real-life experience before entering into a standard, in my humble opinion.

To build on points from @jamieherrera and @Keanem6

If a Web page contains any of the following help mechanisms, and those mechanisms are repeated on multiple Web pages within a set of Web pages, they occur in the same order relative to other page content, unless a change is initiated by the user:

  • Human contact details;
  • Human contact mechanism;
  • Self-help option;
  • A fully automated contact mechanism.

I think the problematic parts are:

and those mechanisms are repeated on multiple Web pages within a set of Web pages

We need to have our sets of screens definition, or use "a mobile application", e.g. "if the help mechanism is repeated in a mobile application, it should have the same relative order to other page content"

In apps, there is usually just 1 screen to find contact details.

But you can usually reach this screen from other screens, e.g. through a help button.

They occur in the same order relative to other page content

This is where it gets challenging, IF the help mechanism is repeated THEN it needs to be in the same relative order compared to other screens.

Note 2 explains:

For this Success Criterion, "the same order relative to other page content" can be thought of as how the content is ordered when the page is serialized. The visual position of a help mechanism is likely to be consistent across pages for the same page variation (e.g., CSS break-point). The user can initiate a change, such as changing the page's zoom or orientation, which may trigger a different page variation. This criterion is concerned with relative order across pages displayed in the same page variation (e.g., same zoom level and orientation).

So we need to "serialize" the page. What do we consider serialize in an app? Is it the accessibility tree? Is is the XML, or Storyboard layout in source code? You either need a specialized tool to extract the a11y tree, or have source code access ( and knowledge of the used framework)

unless a change is initiated by the user

This is not defined, what is "a change initiated by the user"..?

I think we should get some screenshots of apps with help mechanisms on multiple screens and then judge if they would pass or fail this criterion.

jamieherrera commented 4 weeks ago

  1. It will be good to review/ discuss which help mechanisms are repeated in a native app/ hybrid app context (ie should they vary from the list of 4 mechanisms in WCAG?)

  2. @JJdeGroot To your questions on what is "serialized" in an app and what is "a change initiated by the user", some of your quoted text seems to address both:

... how the content is ordered when the page is serialized... The user can initiate a change, such as changing the page's zoom or orientation, which may trigger a different page variation. This criterion is concerned with relative order across pages displayed in the same page variation (e.g., same zoom level and orientation).

So... while there may be additional user change scenarios, we already have some context to guide users that a pass/fail scenario includes not changing orientation or OS text size in the middle of the test, as that may change the order of stuff. No need to look at code at all.

JJdeGroot commented 4 weeks ago

Discussed in today’s meeting.

16 October 2024 [Source](https://www.w3.org/2024/10/16-matf-minutes.html#e019) ~~~text JJ - EN 301 549 marked this success criterion is not applicable. https://labs.etsi.org/rep/HF/en301549/-/issues/278 ACTION: Gather screenshots of help mechanisms in apps for next meeting Jamie - be helpful to get examples of help mechanisms. Mick - My understanding is this SC is only related to to if help mechanisms do exist on a view or screen, that they appear in the same relative programmatic order, it doesn't require them on multiple views. ~~~

ACTION: Gather screenshots of help mechanisms in apps for next meeting

kdrubianoc commented 3 weeks ago

In most apps iOS that I use and checked (for example Instagram, Netflix, MercadoLibre), we often find help in the profile option, then the menu, and find the Help mechanism

qbalsdon commented 3 weeks ago

I know for example "⌘ + /" in Android will show the keyboard shortcuts, and developers can add their own shortcuts to this menu if they programatically register them - are we requiring this as well?

JJdeGroot commented 3 weeks ago

Discussed in today’s meeting.

23 October 2024 [Source](https://www.w3.org/2024/10/23-matf-minutes.html) ~~~text [w3c/matf#43](https://github.com/w3c/matf/issues/43) I know for example "COMMAND + /" in Android show the keyboard shortcuts, and developers can add their own shortcuts to this menu if they programatically register them ⌘ + / julianmka I agree can apply as written with minor word swaps - however floating chat also needs to be considered, like a chatbot julianmka usually floating actions present other accessibility problems on top of consistent help Jamie I feel like including floating help as an additional option or note should exist, not to modify the SC but acknoledge. Looking at the NOTE 3 (ADDED) how does it apply? Does it need to be a set, or just a pattern? I would consider the floating help toelong to this *to belong +1 Joe_Humbert some of this needs to defined at a higher level to avoid the document being overwhelmed. The floating help seems to cover many of the points -1 @joe asking if there is something to call out specifically? *silence* +1 Joe_Humbert to adding this to understanding julianmka we should not conflate the SC too much (like with the keyboard android stuff) +1 to julianmka +1 julianmka +1 to keep as is "view" needs some clarity +1 but yeah +1 +1 +1 ACTION: Propose the draft SC as is for wider group ~~~

ACTION: Propose the draft SC as is for wider group