-
Notifications
You must be signed in to change notification settings - Fork 55
Touch with Assistive Technology #63
Comments
Please ignore accidental bug label here. My fault. |
@kwahlbin The link to the first technique (Using standard one touch controls) is incorrect - it references the template. |
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. |
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.
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. |
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. 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. |
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
|
@mbgower @marcjohlic 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.
But it is starting to feel a bit like a Frankenstein SC. I think it's better to leave separate for draft 1. |
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") |
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:
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. |
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 |
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. |
There are two points of this proposed SC:
|
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. |
I agree with @mraccess77 that this is an important SC. There is no proposal to retire it that I've seen. |
@joshueoconnor |
And related glossary entry.
…nology Touch with assistive technology (was issue #63)
Updated the issue description to reflect the FPWD text |
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. |
@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. |
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 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.
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. |
@DavidMacDonald 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). |
@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. |
@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. |
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.
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. |
@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. |
Current versions of SC and Definitions
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:
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
Benefits
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
Failures
The text was updated successfully, but these errors were encountered: