Touch with Assistive Technology

[kwahlbin]

Current versions of SC and Definitions

• SC for viewing | SC for editing
• Platform assistive technology that remaps touch gestures definition for viewing | Platform assistive technology that remaps touch gestures for editing
• SC in full draft guideline

SC Shortname

Touch with Assistive Technology

SC Text

All functions available by touch are still available by touch after platform assistive technology that remaps touch gestures is turned on.

Suggestion for Priority Level (A/AA/AAA)

Level A

Related Glossary additions or changes

Platform assistive technology that remaps touch gestures: Software that is integrated into the operating system, ships with the product, and/or is updated or installed via system updates. This software changes the characteristics of the touch interface when turned on. For example, a system screen reader may remap a right swipe gesture to move focus from item to item instead of its default behaviour when the assistive technology is not on.

What Principle and Guideline the SC falls within.

New Proposed Guideline "Pointer Accessible"

Make it easier for users to operate pointer functionality.

Editorial Note for WCAG group: Pointer includes "Touch" in its definition

Description

The intent of this Success Criterion is to ensure that content can be operated using gestures on a touch screen with platform assistive technology.

Generally, assistive technology such as a screen reader on a touch screen device will change the gestures that are used to interact with content when it is turned on.

For example, when the platform's screen reader is enabled (e.g. VoiceOver on iOS and TalkBack on Android), users will move their focus to the previous/next element using single swipe left/right gestures; using "touch to explore" functionality, a single tap on the touch screen will set focus to the element at that particular location on the screen; a double tap will activate the element.

While content may provide its own gesture-based controls, all functions available by touch when the platform assistive technology is not turned on must be still available when the platform assistive technology is turned on.

General principles while developing include the following:

• Be familiar with your platform's system controls and standards for assistive technology.
• Use the system controls supported by the platform first
• Don't override the standard gestures of the platform.

Examples

If a developer assigns a double tap as a custom gesture, as the only way to complete an action, a user who is blind using VoiceOver will not have access to that action because VoiceOver reserves the double tap to activate an item.If a developer assigns a swipe right as the only way to open a menu, the VoiceOver user will not be able to do that action, because VoiceOver takes over the right swipe as a way to move from element to element. To avoid this problem, the developer could ensure there is a mobile menu button that works with touch as another way to bring up the menu.

References

• Apple iOS Developer Library: Interactivity and Feedback
• Apple iOS Developer Library: Test Accessibility on Your Device with VoiceOver
• Android Training: Using Touch Gestures
• Google Android Accessibility Help: Use TalkBack gestures
• Windows Phone: Gestures: flick, pan, and stretch
• Microsoft: Use Narrator on my phone
• Samsung User Manual (pdf)

Benefits

• People who are blind and rely on the use of a screen reader while interacting with the touch screen
• People with low vision who may also need a screen reader turned on while interacting with the touch screen

Testability

Test functionally by turning on the assistive technology (AT) for the platform (e.g. VoiceOver on iOS or TalkBack on Android). Conduct QA functional testing such as activating menus, filling in form fields, expanding collapsed content clicking buttons, scrolling down and swiping using the platform gestures. Expected result is that all functionality should be achievable with the AT on.

Techniques

Techniques

• M028 Using standard one touch controls
• M027 Providing touch access for custom controls

Failures

• FM002 Infinite scroll gesture is not available with system screen reader
• FM003 Component can be opened but cannot be closed with touch when a system screen reader is running

[joshueoconnor]

Please ignore accidental bug label here. My fault.

[joshueoconnor]

@kwahlbin The link to the first technique (Using standard one touch controls) is incorrect - it references the template.

[joshueoconnor]

I think this is good - but wonder if it needs to better support the reader. We cant assume any a priori knowledge about what does/does not work with platform AT. I think this needs more examples like those in 'Examples' "If a developer assigns a double tap as a custom gesture, as the only way [...]"

So could we add some of the most common? Or call them out in the supporting materials? I think without fleshing this out a little more readers may be at loss for what to do, and how to satisfy this SC.

[mbgower]

I'll post the same comment I did for #62

This SC seems to be covered by conformance requirement 4. Only Accessibility-Supported Ways of Using Technologies.

Only accessibility-supported ways of using technologies are relied upon to satisfy the success criteria. Any information or functionality that is provided in a way that is not accessibility supported is also available in a way that is accessibility supported.

Do we feel it is necessary to more explicitly capture such requirements in SC?

As I also mentioned elsewhere, IBM has a checkpoint that specifically calls out this conformance requirement. It is very handy as a generic means of capturing failures that are only detected when ATs are turned on. Realizing there is typically an underlying issue that, when determined, can ultimately lead to the failure being classified under an existing SC (typically something like Name, Role, Value), this checkpoint is a nonetheless handy and valuable mechanism for capturing and reporting failures generically before one is able to determine whether something is, for example, a JAWS bug, a developer library issue, an implementation error or a design flaw.

[mbgower]

There are a number of proposed criteria that all seem to be covering the failure of an application to support ATs or platform accessibility features.
Issue #71, Non-interference with Assistive Technology, is an umbrella SC which would seem to encompass the others, which include:
#62 Keyboard with AT
#63 Touch with Assistive Technology (this one)
#68 Speech Input (to a lesser degree)

There are specific comments about considerations from me in each of these. If such a SC is necessary to cover existing conformance requirements, it should be agnostic enough that it can cover all such scenarios without the need for multiples.

[johnfoliot]

Hi Mike, +1 If you are proposing merging those 4 draft SC into one, I could support that. JF

…

On Thu, Jan 19, 2017 at 12:24 PM, Mike Gower ***@***.***> wrote: There are a number of proposed criteria that all seem to be covering the failure of an application to support ATs or platform accessibility features. Issue #71 <#71>, Non-interference with Assistive Technology, is an umbrella SC which would seem to encompass the others, which include: #62 <#62> Keyboard with AT #63 <#63> Touch with Assistive Technology (this one) #68 <#68> Speech Input (to a lesser degree) There are specific comments about considerations from me in each of these. If such a SC is necessary to cover existing conformance requirements, it should be agnostic enough that it can cover all such scenarios without the need for multiples. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#63 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABK-c4S0zB2RzmHtak5VN_DXCLYrW-m7ks5rT6pzgaJpZM4K-jHn> .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com Advancing the mission of digital accessibility and inclusion

[DavidMacDonald]

@mbgower @marcjohlic
I think #62 and #71 should be retired, so no need to merge here.

They are both covered under the existing WCAG 2.0 and reintroducing them with different language in 2.1 will undermine the existing requirements in WCAG 2.0. People will think they are not already covered, and so jurisdictions which require WCAG 2 by law (508, and AODA etc...) may end up with lower accessibility, because of the misunderstanding.

There is a possible merger between #68 and #62. Perhaps it could be an AND statement for WCAG 2.1 Draft 1.

All functions available by touch are still available by touch after platform assistive technology that remaps touch gestures is turned on AND content does not obstruct a user’s ability to access the commands through speech input.

But it is starting to feel a bit like a Frankenstein SC. I think it's better to leave separate for draft 1.

[patrickhlauke]

I'd agree that #62 and #71 should ideally be retired if they can be sufficiently covered by extending the understanding documentation for 2.1.1

#68 feels a bit unfocused to me. i think it really deals more with having visible labels that match the name of a control, rather than any sort of interference with speech AT - see #68 (comment) ... so for the purpose of the discussion here, i'd say it's not relevant

Now specifically for this SC, arguably it boils down to "don't rely on the user's ability to perform a gesture, as that gesture may be intercepted by AT, but offer some alternative control mechanisms". these alternative control mechanisms generally would involve controls that are focusable and actionable, which is generally a hallmark of keyboard-accessible controls. So perhaps the intent here could be crowbarred into 2.1.1.

My only concern though would be that as that SC is pithily called "Keyboard" i'd be surprised if anybody would think that this also applies to touch+AT situations, no matter how explicitly explained this is in 2.1.1's understanding. This is the crux of the lengthy discussion I had on the WCAG mailing lists earlier last year about changing the actual wording of the SC (which at the time I was told was completely unthinkable) to move away from simply "Keyboard" to make it more all-encompassing / include things such as sequential navigation with touch+AT scenarios...which is what led us to having this separate SC in the first place.

So I'd still say that unless the actual name of the existing 2.1.1 SC (and tiny parts of the normative text) can be tweaked to make it a more logical fit, I'd still be weary to roll the concept outlined here simply under 2.1.1 (though at a stretch, if the understanding were to very explicitly explain that many "with AT" scenarios boil down to something very akin to a keyboard/keyboard-like navigation, and that therefore 2.1.1 also applies there, i could barely live with that...but 2.1.1 does still have some in my mind limiting wording that would make it an ill-fit currently at best, such as the use of "keystroke")

[patrickhlauke]

Trying to locate the lengthy thread on WCAG mailing lists I referred to above, but failing. In short, my main contention (from memory) on 2.1.1 is:

• it uses the word "Keyboard" which doesn't make it immediately obvious it also applies to things such as touch+AT scenarios
• scenarios such as touch+AT are not "keyboard interfaces" in the WCAG 2.0 definition https://www.w3.org/TR/2008/REC-WCAG20-20081211/#keybrd-interfacedef as they do not generate "keystrokes" for certain things - for instance, if I swipe left/right to move to AT focus, i don't generate a TAB/SHIFT+TAB keystroke...the AT simply instructs the UA to move the focus. if a site complies with the wording of 2.1.1 as it currently stands and listens just for actual keystrokes, it will not catch these interactions at all

So my proposal at the time was to generalise the SC name itself slightly (I believe I floated some, admittedly awkward, terminology like "Non-pointer input" or similar, which is certainly open to bikeshedding), to use terms like "sequential navigation inputs", "keyboard and keyboard-like interfaces" etc, and to deemphasize the use of "keystrokes" since that won't apply to things like touch+AT, speech AT (which does trigger some keystrokes, but similar to touch+AT not always, e.g. when moving the AT focus explicitly to certain elements).

If it is now back on the table that perhaps we can modify 2.1.1 / existing WCAG 2.0 SCs going into 2.1, then I'd be happy to see the above tweaks done to 2.1.1 and to retire this particular SC. Otherwise, I do feel there are nuances to touch+AT in particular that are not well suited to be simply assumed/rolled into 2.1.1 as it stands.

[patrickhlauke]

Dredging this up from the depths...my original proposal to modify 2.1.1

https://lists.w3.org/Archives/Public/public-mobile-a11y-tf/2016Jul/0009.html

[DavidMacDonald]

Yes, a long thread with a lot of time and ink for some of us (25 hours for me) ... at the time I had a legal draftsman look at the proposed wording and he felt it left some holes in the current requirements, and he didn't know how to fix it in a way to make it more generic. My issue at the time was that 2.1.1 is one of the few SCs that "Johnny lunch box" developer actually understands. "unplug the mouse and test the site" and every new iteration I saw, looked confusing and had holes. So I suggested we leave it for the first round, vet the new SCs, and monitor it as WCAG 2.1 matures.

I think for the first draft, due in 4 weeks, we should keep this separate. And see what comes back from our stakeholders, and see if an insightful person "might" be able propose an elegant solution without it becoming too abstract, and confusing, and still meet all the current keyboard requirements.

[mraccess77]

There are two points of this proposed SC:

1. that screen reader users wouldn't be forced to carry around a physical keyboard to access something and 2 that a keyboard accessible control on desktop may be inaccessible on mobile -- that is if an element was touch accessible to a user without a disability it should be touch accessible with. At this point Gregg V. would say what's required is a keyboard interface and not a physical keyboard. However, given the inability to send keyboard interface commands on iOS and the inability of Safari to pass keyboard interface commands to the web page makes this a problematic issue. Common issues include ARIA combo boxes where the user can press up or down arrow on a desktop to change the selection. However, on iOS I not been able to find a way to pass up and down from an AT nor from an on-screen keyboard to the web page. Thus, making a keyboard accessible ARIA combo box inaccessible to a screen reader user on iOS. It passes SC 2.1.1 because it supports up and down arrows - but it's not usable to a person who relies on a screen reader. This is what we discussed many times over the 3 years on the TF and yet it doesn't seem to be captured and we are slashing SCs like fruit ninjas.

[patrickhlauke]

This is what we discussed many times over the 3 years on the TF and yet it doesn't seem to be captured

that was buried somewhere in my 600 pages of arguing why "keystroke" in 2.1.1 didn't cover all angles...

if the WG is amenable to modifying existing 2.1.1 in 2.0 to make it more holistic in 2.1, then this aspect would of course need to be emphasised/reinforced (inability to arbitrarily raise a keyboard, thus having situations where reliance on listening for keystrokes will still result in inaccessible content that nominally passes 2.1.1)

Related, dropping in the "ARIA Design Patterns and touch device support" https://w3c.github.io/aria-in-html/#aria-touch note, which mentions problems such as the ARIA combo box issue.

[DavidMacDonald]

I agree with @mraccess77 that this is an important SC. There is no proposal to retire it that I've seen.

[DavidMacDonald]

@joshueoconnor
Are we ready to do a pull request on this?

[awkawk]

Updated the issue description to reflect the FPWD text

[joshueoconnor]

Hi @DavidMacDonald and @kwahlbin - Just a heads up that there were two definitions in the SC description here such as Touch with AT - viewing, and Touch with AT - editing - but these terms do not exist.

[joshueoconnor]

@DavidMacDonald and @kwahlbin - sorry, I thought these were terms used in the SC! They weren't, so ignore my last comment. However, if there are terms that need to be linked here that we are missing please let me know.

[DavidMacDonald]

Public and member comments
#263, #234, #195

[DavidMacDonald]

There seems to be a number of comments that ALL functionality is too wide, we are on the other hand hearing a lot of support for the SC. Perhaps we should narrow the scope to identify 5 of the frequent offenders when a screen reader is turned on.

The following functions are still available by touch after platform assistive technology that remaps touch gestures is turned on:

• Changes to the page as a result of a gesture [such as autoloading content on scroll down]
• Form elements
• Navigational content
• Selectable content [such "add to shopping cart"]

The other way to look at this is that, if we ensure that accessibility support in WCAG 2.1 is tight enough to explicitly require the mobile view to conform even if the Desktop conforms, and not use "conforming alternative language as a "get out of jail free" card, then we that would cover the requirements of this SC. The consensus from previous chairs (Gregg and Loretta, and those of us who were there), is that WCAG 2 requires this, but needs explicit mention as an editorial update to the conformance section. I filed an issue on that on 2.0 to provide an editorial amendment.

The full page includes each variation of the page that is automatically customized for various screen sizes. Each of these variations (or their respective conforming alternate versions) needs to conform in order for the entire page to conform. However, if a user actively chooses a setting on the page that optimizes or personalizes the state of the page for accessibility reasons, this new state does not necessarily need to conform, because the conforming version can be reached by undoing the setting.

It would be placed after the last paragraph in the section "Understanding Requirement 2" (just before the Notes at the end of the section. https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-conformance-requirements-head

This would be my preference, because it is in WCAG 2, and well established in law and policy.

[detlevhfischer]

@DavidMacDonald
I think enumerating the types of content to which this SC should apply is problematic - any finite enumeration risks missing essential types of content. It might be easier to adress sensible exceptions.

The text of the suggested editorial amendment explaining that the "full page includes each variation of the page that is automatically customized for various devices" sems to miss situations where LV users zoom in and thereby trigger breakpoints for designs that then fail to conform - authors might simply argue "this new state does not necessarily need to conform, because the conforming version can be reached by undoing the setting" (reducing the zoom factor).

[mraccess77]

@det wrote "this new state does not necessarily need to conform, because the conforming version can be reached by undoing the setting" (the zoom factor).

This is a problem because you can only conform when not zoomed in but some users need to the zoom in version to use the page and zoom is required for conformance.

[DavidMacDonald]

@mraccess77 Can (does) Resize text #77 plug this "hole". If not, is there something we can do to plug it #77. Perhaps then we can rely on the editorial change and retire this SC. the SC seems to be getting more resistance than I anticipated, given that everyone has been asking for mobile SCs.

[DavidMacDonald]

As the author of this issue, I would like to suggest we address this issue in the conformance document. For 2.1 we could add a paragraph to the section on conformance.

The full page includes each variation of the page that is automatically generated by the page for various screen sizes. Each of these variations (or their respective conforming alternate versions) needs to conform in order for the entire page to conform.

It would be added here at the end of the section:

https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-conformance-requirements-head

to the new 2.1 (not 2.0 because some interpret it as a change). If this amendment is accepted by the group, I'd be open to retiring the issue.

[kwahlbin]

@DavidMacDonald we cannot retire this SC. We can have the recommendation be to add information to the conformance document but it should include the information that you listed above about responsive AND information about both keyboard and touch access the assistive technology. I think that is a good way to go and I will support that if we have both pieces of information added to the conformance document.

[DavidMacDonald]

@kwahlbin @awkawk We may want to get it on the Main group agenda fairly soon. It has never been discussed by the wider group and we have less than 12 weeks before we have to have AWG consensus on all SCs worked on by the group.