- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Fri, 15 Jul 2016 09:35:00 +0100
- To: "public-mobile-a11y-tf@w3.org" <public-mobile-a11y-tf@w3.org>
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 08:35:23 UTC