w3c/mobile-a11y-extension

WCAG Extension drafted by Mobile Accessibility Task Force

Mobile-A11y-Extension

WCAG Extension drafted by Mobile Accessibility Task Force

mobile-a11y-extension's Issues

Proposed new SC "4.1.3 Non-interference of AT" is not mobile-specific

In current https://w3c.github.io/Mobile-A11y-Extension/ there's

[Proposed New MOBILE Success Criteria] 4.1.3 Non-interference of AT: Content does not interfere with default functionality of platform level assistive technology

It feels odd to me that this is flagged as being MOBILE specific. The idea of non-interference should be just as applicable on all other platforms (dekstop, laptop, etc) where AT is available.

"Guideline 3.4 Make content usable in device orientations." possibly more suited under "Principle 4: Robust"?

In current proposed https://w3c.github.io/Mobile-A11y-Extension/ we have

Guideline 3.4 Make content usable in device orientations.[MOBILE]

3.4.1 Orientation: Orientation of the content is not locked to landscape or portrait, except where orientation is essential.

I'm wondering if this wouldn't fall more under Principle 4: Robust? While at the moment this principle seems concerned with "mechanical" robustness (that UAs, including AT, can interpret content correctly)

Principle 4: Robust - Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

it "feels" to me that having content/applications that work well in different viewports/screen sizes/screen orientations is also a measure of robustness (though admittedly, to make it fit, this may require an expansion to the "Principle 4" wording to allow for new SCs other than purely mechanical ones to be included.

"Mobile Techniques proposed for WCAG 1.3.1" perhaps more appropriate for 4.1.2 and 3.3.6 ?

In https://w3c.github.io/Mobile-A11y-Extension/ we currently have

1.3.1 Info and Relationships

Mobile Techniques proposed for WCAG 1.3.1

M006 Data Type: Specifying input type for numerical or character data
M008 Data Mask: Set the virtual keyboard to the type of data entry required
M023: Set the HTML virtual keyboard to the type of data entry required.
M024: Set the iOS virtual keyboard to the type of data entry required.
M025: Set the Android virtual keyboard to the type of data entry required.

I'm not quite sure these relate to 1.3.1

1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

as they don't seem related to what's conveyed "through presentation".

Setting the correct input type feels to me more aligned with 4.1.2

4.1.2 Name, Role, Value: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; [...]

arguably, the type of an input could be considered its "role" (beyond just the basic "this is an input"), and that also helps determine the "values that can be set by the user".

Making sure that the correct keyboard etc is triggered (by setting the correct input type) also feels like it would fall under the overarching idea of 3.3

Guideline 3.3 Input Assistance: Help users avoid and correct mistakes.

as it helps users avoid mistakes (by NOT showing inappropriate on-screen keyboards). At a stretch, this could conceptually fall under the current 3.3.6

3.3.6 Error Prevention (All)

as having the correct keyboard would prevent users from entering invalid characters. However, the current SC's wording would need to be expanded to cover this scenario (as this idea of triggering correct keyboard doesn't fall neatly under any of the sub-points: 1) reversible 2) checked 3) confirmed)

"Mobile Techniques proposed for WCAG 1.4.3" perhaps redundant?

In current https://w3c.github.io/Mobile-A11y-Extension/ there is a proposed technique

[MOBILE] Color Contrast: The default point size for mobile platforms might be larger than the default point size used on non-mobile devices. When determining which contrast ratio to follow, developers should strive to make sure to apply the lessened contrast ratio only when text is roughly equivalent to 1.2 times bold or 1.5 times (120% bold or 150%) that of the default platform size.

Unless I'm missing something, this technique doesn't actually say anything different from the regular color contrast advice, with exception of perhaps talking about the "default point size" (which is already a bit contentious due to its use of points rather than px, and is - from what I understand - slated to be reviewed for future WCAG iterations). Therefore, I'd suggest dropping this, as it adds nothing in my view.

"Guideline 3.5 Make interactive elements distinguishable" more suited to COGA/LowVis?

Looking at https://w3c.github.io/Mobile-A11y-Extension/ the (then) proposed

Guideline 3.5 Make interactive elements distinguishable

3.5.1 Triggers Distinguishable: Elements that trigger changes should be sufficiently distinct to be clearly distinguishable from non-actionable elements (content, status information, etc). [MOBILE]

seems more suited to the task forces tackling cognitive and/or low vision. suggest removing this from the mobile TF proposals

Various input-specific proposed new SCs

Looking over https://w3c.github.io/Mobile-A11y-Extension/ there's a whole slew of proposed new SCs relating to input.

[Proposed New MOBILE Success Criteria] Visual gestures to the camera

[Proposed New MOBILE Success Criteria] Voice control using microphone

[Proposed New MOBILE Guideline] Guideline 2.7: Make it practical for speech input users to operate all functionality

As ever, it is unclear to me why these have been specified as MOBILE...they seem to be platform-pervasive

[Proposed New MOBILE Success Criteria] Speech Input: All functionality of the content (including touch and gesture) is operable through the keyboard, and does not obstruct a user's ability to access the keyboard commands through speech input. (Level A)

This is yet another variant of 2.1 / 2.1.1 ? (relating to the lengthy discussion https://lists.w3.org/Archives/Public/public-mobile-a11y-tf/2016Jul/0009.html and https://lists.w3.org/Archives/Public/public-mobile-a11y-tf/2016Jul/0096.html)

[Proposed New MOBILE Success Criteria] Single key shortcut alternative: The user can adjust any single key shortcut to an alternative control of a string of symbols and letters.

this feels like a customisation/personalisation thing, again valid not just on MOBILE.

One of my main concerns here is that we seem to have taken on board any form of input stuff - making the majority of work in the TF essentially the "Input mechanisms TF" (with a sprinkling of personalisation), but I'd posit we may not have a broad-enough representation of expertise in the TF (and since it's badged as being "MOBILE" it may not even occur to people that this is the sort of work that's potentially being discussed here)