w3c/mobile-a11y-tf-note

Editor's Draft of W3C Note. "Mobile Accessibility: How WCAG 2.0 and UAAG 2.0 Apply to Mobile Devices" from the Mobile Accessibility Task Force of the WCAG WG and UAAG WG.

Mobile-A11y-TF-Note

Editor's Draft of W3C Note. "Mobile Accessibility: How WCAG 2.0 and UAAG 2.0 Apply to Mobile Devices" from the Mobile Accessibility Task Force of the WCAG WG and UAAG WG.

To write or edit a Technique

Open the Techniques folder to see the files for individual Techniques. Technique files are numbered. M000.html is the template for creating new techniques.

To write a technique

1. Navigate to the Mobile-A11y-TF Github repository: https://github.com/w3c/Mobile-A11y-TF-Note
2. Click on the techniques folder
3. Click on the pencil icon (near top right) to edit
4. Click on the file numbered with your technique number
5. Replace the text that appears in all caps

When you’re finished
1. Click the green “Proposed File Change” button below the file
2. Click the green “Create Pull Request” button above the file
3. Click the second green “Create Pull Request” button that appears after you click the first one

Your changes will appear in the file when Jeanne approves the pull request.

When you’re ready for people to comment on your technique send the link to the list and invite people to comment by following the link and leaving comments on the Github file.

To propose changes to main document "How WCAG Applies to Mobile"

1. To edit the Main Note file, fork index.html. The MobileQuickRef.html is Appendix A.

mobile-a11y-tf-note's Issues

1.1 bullet 3 "mobile" screen size

Recommend changing the word "mobile" to "various"
web pages utilizing responsive design can transition to various screen.....

Change "should" in section 3.4 to "required"

I think the mention of keyboard in 3.4 is a bit soft ... It says "should" rather than "must"
"Therefore, even when device manipulation gestures are provided, developers should still provide touch and keyboard operable alternative control options.

Although earlier in the document, Section 3.1 says "keyboard accessibility remains as important as ever"... I don't think think that is clarifying that Keyboard accessibility is necessary to conform to WCAG when applied to Mobile.

Section 3.4 (current)
"Therefore, even when device manipulation gestures are provided, developers should still provide touch and keyboard operable alternative control options. "

(Recommendation)
"Therefore, even when device manipulation gestures are provided, in order to conform to WCAG, developers still need to provide touch and keyboard operable alternative control options.

3.1 Keyboard Control: mobile SR navigation benefits from focusable elements

Many considerations that are nominally for keyboard (such as focus order, and the fact that elements that are actionable need to also be keyboard-focusable) are equally valid for users of screen readers on touch-screen devices. While VoiceOver/iOS (because of the way its navigation works) lets users focus even on non-focusable elements (such as a <span> for instance), TalkBack/Android does not, depending on the specific way a control was coded...in most cases, if there's no actual text content (so for instance an empty <span> with only some CSS-based indicator, like an icon font or CSS background image, will simply not be focusable/navigated to, and therefore cannot be triggered).

It may be worth mentioning this aspect as well?

Clarify sentence regarding "both orientations"

• the following sentence about orientation is confusing to me. I read it 4 times and am still not sure what it means.

"Therefore, mobile application developers should try to support both orientations. If it is not possible to support both orientations, developers should ensure that it is easy for all users to change the orientation to return to a point at which their device orientation is support"

It's the part about "ensure that it is easy for all users to change the orientation to return to a point at which their device orientation is support"

that confuses me...

ambiguous word "whether" in 4.6 regarding keyboard alternatives

4.6
"Therefore, instructions (e.g. overlays, tooltips, tutorials, etc.) should be provided to explain what gestures can be used to control a given interface and whether there are alternatives. "

I think the word whether leaves it ambiguous whether there need to be keyboard alternatives. I think WCAG requires keyboard alternatives for all gestures.

Clarify 4.4 sentence regarding "same destination" links

4.4
This sentence confuses me

"When multiple elements perform the same action or go to the same destination (e.g. link icon with link text), these should be contained within the same actionable element. "

I guess it means, put the linked image and image text in the same anchor. But I had to read it 4 times.

Add a bullet or Note to 3.3 to make keyboard equivalents explicit

I think 3.3 needs a bullet with explicit mention that every touch gesture should have a keyboard equivalent, although there is a bullet in 3.4 about this it's not clear that this is necessary for 3.3 issues in the mobile doc.

perhaps there is no mention of a keyboard equivelent requirement because of the exemption in 2.1.1
"except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A)"

This WCAG exemption was intended for drawing programs and when the user uses a mouse to draw something...I don't think the exemption should apply to gestures even though they depend on the "user's movement between endpoints".
Suggestion:

Note: In order to meet WCAG SC 2.1.1 any outcome accomplished by a gesture would need to have a keyboard alternative.

Set the virtual keyboard to the type of data entry required -- are we pro or con?

Item 4.1, "Set the virtual keyboard to the type of data entry required", sounds like it's making a positive recommendation—but then it goes on to say "Setting the type of keyboard…can be confusing for people who are using a screen reader when there are subtle changes in the keyboard."

So is this actually a recommendation not to set the virtual keyboard?

Robust or operable?

Section 4 of the document is titled "Mobile accessibility considerations related primarily to Principle 4: Robust". Isn't robustness about making sure that content can be interpreted by a variety of user agents?

These items—"Set the virtual keyboard to the type of data entry required", "Provide easy methods for data entry", and "Support the characteristic properties of the platform"—sound like they relate rather to Principle 2: Operable.

2.1 Small Screen Size

Best Practices - Bullet item 1 - suggest focusing on designing for mobile version that considers design aspects versus tailoring content.In my opinion, content on mobile devices and desktop/laptop should be consistent and contain same information.

Preview not displaying under HTTPS

(this was reported via email to [email protected])

In my console, I get the following notification, so I guess all that is needed to address the issue is to change http://www.w3.org to https://www.w3.org on external resources

[blocked] The page at https://w3c.github.io/Mobile-A11y-TF-Note/ was not allowed to run insecure content from http://www.w3.org/Tools/respec/respec-w3c-common.

(I assigned it to everyone who worked on the index.html ever (but @patrickhlauke because it didn’t let me) because I don’t know who’s responsible for making the change :-D)

Section 4.2, "Consistent" in WCAG 3.2.3 is limited to "Navigation"

Section 4.2
"Components that are repeated across multiple pages should be presented in a consistent layout....Consistency between the different screen sizes and screen orientations is not a requirement under WCAG 2.0."

This infers that consist component layout is required within screen sizes.

I don't think this is quite what WCAG was getting at with SC's 3.2.3, 3.2.4.
3.2.3 was really just about left
**

navigation
**
menus, rather than components, and 3.2.4 was about labeling and identification rather than placement. I'm not saying that authors shouldn't
place other things consistently
, but I think this could lead to confusion about Consistency as it is required in WCAG
, which it isn't from my memory of those discussions and the current WCAG text.

3.2.3 Consistent Navigation: Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user.

3.2.4 Consistent Identification: Components that have the same functionality within a set of Web pages are identified consistently. (Level AA)

I think section 4.2 of the mobile requires some rewriting
to correct this confusion.

3.3 Touchscreen gestures mentions mouseup and touchend, but not click?

Activating elements via the mouseup or touchend event.

I'd say a more robust, input-agnostic piece of advice would be to listen to the click event, as it's device-independent (when talking about actual JavaScript events)

Hand tremors and the giant-button-problem

Hampus Sethfors makes a good point in the article, Hand tremors and the giant-button-problem. Should it be included in this document?

4.5 add the word "inline" to Conventional style for links

4.5
-Conventional style: Underlined text for inline links, color for link

(Groups of navigation elements don't need underlines.)