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

On 15/07/2016 13:08, David MacDonald wrote:

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

My aim is nothing to do with "making it shorter". It's about making it 
rational and not splitting things that say the same thing into separate SCs.

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

Explain how that is differently handled in the touch+AT scenario from 
the keyboard scenario please.

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

Such as ?

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

No, the proposed language expresses the need for users, regardless of 
their input modality, being able to operate things and not get trapped. 
How they achieve this is a different matter. They can use input-agnostic 
high-level events like focus/blur/click, or they can - if they fancy it 
- use 
mouseover/mouseout/mousedown/mouseup/keydown/keyup/keypress/focus/blur/click. 
It's up to them.

> It relies on the techniques to explain to developers what we
> are talking about. That to me is subject to much confusion.

Not really. It says to developers: regardless of input, users need to be 
able to do this. If the developer than wonders "well, what is really 
meant? how do i achieve this?" they go looking in the understanding and 
the how to meet documentation. This is no different from most other 
current SCs.

> Indie UI was disbanded. Are we going to solve that in WCAG 2.1?

No, and I never brought up IndieUI. And it's not required/needed for 
what I'm proposing.

>  I'd say
> the proposal to combine everything a super ambitious,  and perhaps would
> may be better suited for Silver.

If there's continuing pushback even in this group to actually tackle the 
fundamental problem...then sure, let's just duplicate things and 
rationalise it in Silver/WCAG.next/WCAG 3.0

> And who knows, by then some
> manifestation of Indie UI may have emerged and perhaps User Agents will
> be on board ....

By then we may have all ascended to a higher state of consciousness 
(depending on timelines) ;)

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 12:19:58 UTC