Re: user-adaptation SCs

Apologies for the long email, skip to “One last proposal” if you are short on time…



Wayne wrote:

> I think we need identify some necessary accessibility holes in web component encapsulation.  We may even need to identify a protocol for communication.



Without disagreeing (I don’t know yet), I think that is a tangent to the current discussion?





> Background images included important content. (Not protecting the need for color choice)



We regularly fail sites which rely on background images for content, is there a situation where they pass WCAG 2.0 that isn’t covered?





> No semantic markup (Like an ARIA role "semantic-style") indicating that style is being used for the author's private semantics.

​ ​

I’m not clear what that means, if they are private semantics then surely they have no bearing on what a user-agent should do?





> ​No ARIA support for identifying visually hidden.​



That information is already available to a browser, I’m not clear what adding to ARIA would help support?





> There was no to fill out forms enlarged that reflowed​



Sorry, I’m not clear what that means, but would that be covered by the Resize content or Linearise SCs now?





​> Contrast that with the case of Meaningful Sequence. This encouraged the CSS WG to implement Flex Box with the following limitation: Authors must use order only for visual, not logical, reordering of content. Style sheets that use order to perform logical reordering are non-conforming.



Actually there is an argument about that, quite a few people (e.g. IBM, TPG) are arguing that the browsers & AT should follow the *visual* order created by Flexbox. I agree with that, having multiple interfaces always ends up with the less obvious one being forgotten.



That is also why my bookmarklet keeps the created flexbox order, rather than just neutralising flexbox completely.





> The lesson here is that access that is protected by normative language influences decisions and if WCAG doesn't mention it in normative language then developers will find many innocent ways to interrupt access.



And we have the principles in the proposed SCs, but they will be at risk unless we can translate that into clear *content* guidance.



I think the closest equivalent problem in WCAG 2.0 is 2.1.1 Keyboard, that is close to being a /test-oriented/ SC. I.e. you test it by using a user-agent. However, it has clear content-oriented techniques such as using HTML form controls, keyboard-triggered event handlers etc.

You could use a script to highlight every element on a page that has mouse event but doesn’t have a keyboard event, so in theory you can test it without use a user-agent.



That doesn’t seem to be the case for the user-adaptation SCs, at least not yet.





> ​One last proposal. All style access should be at the element level. There is good reason to have different styles applied at different levels. We need to define a new visual semantic for our individuals.



That sounds like it will take longer that the 2.1 timeline?



Overall I see several levels:



1.      Adaptation that works under the author-controlled styling/scripting in a default browser, such as Resize content.

2.      Adaptation that subtly over-rides author styles, such as text-color.

3.      Adaptation that will likely break layouts, such as linearisation, spacing, font-family. Also several from COGA that I’ve seen, such as adding icons to the text.

4.      Personalisation where the website provides options for the user, or in some way works with the user’s settings.



Level 1 & 2 are reasonable in the WCAG 2.x framework. I think level 4 will have to go into Silver.



Level 3 is the interesting one, and if it is a case of the user over-riding styles (so little for the author to do), then it should work. If we need to define all the techniques and failures for adaptation *within* the authors styles, that is a huge amount of work.



For example, even on the best websites adding 1em spacing around items in a horizontal menu will cause wrapping or overlap, and probably cause drop-downs to fail or overlap. I could not point developers to a method to cater for that.



That doesn’t matter if we assume the user has over-riden the layout (e.g. linearised it), but if it is supposed to be within the authored styles, we have a big problem.



Cheers,



-Alastair