Re: Proposal: expanding/modifying Guideline 2.1 and its SCs (2.1.1, 2.1.2, 2.1.3) to cover Touch+AT

David wrote:

“I think it's probably premature for the industry, but I could get back on the fence, if we explicitly require Keyboard in the proposal not as an example but as a fundamental part of the definition, and we specifically require functionality to work with system remapping AT turned on, which is my biggest concern with mobile a11y.”



I’m struggling to understand where the proposal [1] doesn’t do this, at least in principle.



Slightly updated with ‘including’:

“All functionality of the content is operable through accessibility supported non-pointer input interfaces (including keyboards), without requiring specific timings for individual interactions, ​except…”



My reading is basically: Make sure you can do everything without a mouse, including using a keyboard. This seems good, minor point about the term “non-pointer input” aside.



I don’t think it does impact the new 2.5.1, as that is tackling a different issue. (That of a touch interface changing with the AT applied.)



Working to the new 2.1 should make 2.5.1 easier to meet, but there are issues (e.g. relying on touch-swiping) that are not covered by the current or proposed 2.1.



An example might help, let’s take an image slider/carousel that lets you move through a set of images. (Patrick, you might need to correct the details, but I think the premise is valid?)



For the next / previous functionality you could fail on all counts by using mouse-specific events attached to the left/right sides for previous/next, and swipe detection (touchstart, touchmove, touchend). This fails 2.1 current and proposed, and 2.5.1 I believe (because swipe is used for navigating with AT).


You could pass current 2.1 by adding keyboard events, but fail 2.1 proposed, and fail 2.5.1.



You could pass current and proposed 2.1 by using keyboard and mouse event-handlers, but if a touch interface relies on detecting swipes that would still fail 2.5.1.



You could pass them all by making adding previous/next buttons (i.e. tab-able) with an on-click handler, as that works as a high-level event, works with touch interfaces, and doesn’t require a swipe (but the swipe could still be enabled).



Have I missed something?



Cheers,



-Alastair





1] Took me a while to find: https://lists.w3.org/Archives/Public/public-mobile-a11y-tf/2016Jul/0009.html