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

If I get it correctly, David's point is that there are behaviours with current touch+AT that do not (or not sufficiently) map onto keyboard (sequential) access.
He is concerned that we end up with generalised requirements that miss out on specific author guidance that ensure a11y on common mobile OS.

I hope it is consensus that only those things that authors can implement without having to introduce very specific variant solutions targeting particular UA/AT should b considered valid additions to WCAG - whether as additional SC or as modification / generalisation of existing SCs like 2.1. This was Chris' point yesterday - techniques catering to specific sets of UA/AT can make matters worse for other scenarios, plus require a lot of coding effort without being robust.

To make it easier to get to a good solution regaring SCs for WCAG 2.1, I still think it would be useful to collect some examples where sequential access may differ between keyboard navigation and touch-AT sequential navigation. We may then look at these in turn and try to decide whether a difference is really something that UA makers or OS / AT makers need to take care of, or whether it is something that is pertinent enough to set up an author requirement.

I start with Example 1 and hope others will add more examples so we have something to chew on.

---------
Example 1: pop-up dialog ( http://www.3needs.org/en/testing/code/role-dialog-3.html  )
# Keyboard navigation: Dialog can be opened with enter, dialog h3 (linked via aria-labelledby) is announced, the kb focus kept inside dialog and moved back to trigger when dialog is closed.
# Swipe navigation (iOS/VoiceOver): Dialog can be opened with double tap, dialog h3 not read, kb focus is not kept in dialog but moves to browser chrome. But swiping back moves straight to last element in dialog.
# Swipe navigation (Android/TalkBack): Dialog can be opened with double tap, dialog h3 not read, kb focus is not kept in dialog but moves to browser chrome. Swiping back does NOT return to focus last element in dialog.

So there is are differences in terms of sequential navigation. The author advice (via @cookiecrook) to ensure that the AT swiping focus doesn't wander off into the page background was to apply aria-hidden to the rest of the page AFTER moving focus to the dialog div. So this is something that might be captured as an ARIA technique for meeting SC 2.4.3 - but note that even then, on both touch+AT cases there is no way of keeping the focus in the dialog.
---------

Even if the example does not directly address 2.1.1, it makes the point that there are differences regarding navigation when comparing desktop kayboard and sequential touch+AT navigation.

Collecting more such exampes would give us a better handle as to what author requirements are reasonable, and what other issues must be left to improvements of OS/AT or UA.

I think it also ultimately helps deciding whether we need to generalise SCs so they also address non-pointer input or whether we will fare better with separate SCs. Agree?

Best, Detlev




--
Detlev Fischer
testkreis c/o feld.wald.wiese
Thedestr. 2, 22767 Hamburg

Mobil +49 (0)157 57 57 57 45
Fax +49 (0)40 439 10 68-5

http://www.testkreis.de
Beratung, Tests und Schulungen für barrierefreie Websites

Patrick H. Lauke schrieb am 15.07.2016 10:35:

> On 15/07/2016 05:53, David MacDonald wrote:
> 
>> John Foliot expressed an opinion about SC bloat. He wrote:
>>
>> "I am not that concerned about “bloat” – the requirements are the
>> requirements are the requirements. The web as a platform has grown
>> significantly more complex and sophisticated over the 8+ years since the
>> original WCAG 2.0, and overall the developer’s toolbox has also grown
>> exponentially. I don’t think it is unreasonable to then expect that
>> accessibility requirements have also expanded in direct relationship to the
>> level of complexity introduced by today’s modern web development
>> practices...I’d suggest that [SC] filtering could be performed on web sites
>> and/or within tools, as already demonstrated in the WCAG Quickref – I
>> don’t
>> think we need to worry about quantity as much as we need to ensure we have
>> the right number: not too many, but not too few."
>>
>> https://lists.w3.org/Archives/Public/w3c-wai-gl/2016JulSep/0200.html
> 
> I knew you were going to reference this here at some point, but note: 
> the way you framed your discussion on that mailing list was the removal 
> of SCs
> 
> "Are there any SCs that have been overcome sufficiently by the 
> environment, OS, User Agents etc. that we can remove them without 
> breaking the acceptance requirement of WCAG 2.1 that meeting it also 
> meets 2.0?"
> 
> Hence John's comment is to be read in light of "no, we can't just 
> remove/hide old, but still valid, SCs". As the point HERE is that I'm 
> not trying to hide/remove keyboard access, but rather expand it so we 
> don't end up with (to my mind) unnecessary splits like:
> 
> - must work with keyboard
> - no keyboard trap
> - must work with keyboard (no exception)
> - must work with touch+AT
> - no touch+AT trap
> - must work with touch+AT (no exception)
> - must work with other AT like speech recognition
> - no other AT trap
> - must work with other AT (no exception)
> 
> As all those separate SCs will need to be supported in order to claim 
> compliance, and because the solution to cover all three of those cases 
> boils down to the same concept (using input-agnostic high-level JS 
> events, as already advised in techniques already like 
> https://www.w3.org/TR/WCAG20-TECHS/SCR35.html).
> 
> In the case of authors thinking "well, my site/app only targets this 
> platform which is guaranteed never to have touch+AT scenario since it's 
> a custom point-of-sale terminal with only a keyboard", sure they could 
> simply skip the touch+AT related SCs as non-applicable...but if these 
> were all combined into a more holistic set of SCs, they could still 
> apply them, and simply ignore the touch+AT aspect and exclude that 
> particular AT scenario in their conformance claim on the grounds that 
> that particular AT does not actually exist for their target platform.
> 
> P
> -- 
> Patrick H. Lauke
> 
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>

Received on Friday, 15 July 2016 11:46:25 UTC