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

I think John's comments can be read in their own light... It is certainly
my feeling also.

For 8 years we've been getting complaints about the length of 1.3.1.
Critics and almost every WCAG commenter has said we should have broken it
up to separate SCs. I am concerned we are going down the same rat hole with
2.1.1 which is already a huge SC. We're not making WCAG any shorter by
lumping it all together, and I would say making functionality working in
all these technologies will requires more than simply using onclick. i.e.,
We've got the infinite scroll issues on mobile with VO, etc... so I'm also
concerned our sufficient techniques are going to have tons of "AND"
 statements joining two or 5 techniques to combine them. I'm also concerned
that some things required in our previous 2.5.1 will get lost if running
AT, a high level layer is lumped in with keyboard a lower layer activity.

I'm worried that my main concern for 2.5.1 that running the system AT will
not bd covered sufficiently because it is buried.

We'd have to explore that before trying to roll everything into one.

We have here an SC aimed at requiring developers to use high level events,
but it has no mention of high level events in the normative SC language. It
relies on the techniques to explain to developers what we are talking
about. That to me is subject to much confusion.

Indie UI was disbanded. Are we going to solve that in WCAG 2.1?  I'd say
the proposal to combine everything a super ambitious,  and perhaps would
may be better suited for Silver. And who knows, by then some manifestation
of Indie UI may have emerged and perhaps User Agents will be on board ....

At the very least, getting all the stakeholders on board and getting the
language right may take up all our bandwidth. I'd rather get the
requirements in the SCs right, get approval, and then think about ways to
economize on the number of SCs, later.




Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*
Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Fri, Jul 15, 2016 at 4:35 AM, Patrick H. Lauke <redux@splintered.co.uk>
wrote:

> 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
>
>
>