Re: Proposal for support personlization AA from John, Chris, Jan and myself

> The fact that the AA requirement does so without requiring a "taxonomy" is important, because there is no taxonomy.

That isn’t really true, there is one now. There is a list of items (75 in three categories), so what is needed is refinement of that to a point that we’re happy to create sufficient techniques.

The list of “terms” is already there, it was in Lisa’s email. What I was suggesting was that a version of those terms & descriptions is created by either:

  *   Including it directly in WCAG 2.1 as part of that SC’s material, or
  *   Modularising coga-personalisation, and the first module is just the destination/action/field part. (Perhaps rename to “Accessibility Personalisation”, or something more general.)

This is a less flexible approach, but it would be a concrete set of things that sites could implement immediately with little fuss.

The whole point is that it is fairly universal, and applies across websites, so what you are getting is a cross-site set of conventions.



> This version of the requirement acknowledges that, and encourages I suppose "domains" to use their own consistent methods, WHATEVER those may be.

Before you spoke about different sites creating many different (probably terrible) ways to implement their own solutions, I think this encourages industries to do the same at the taxonomy level.


> For example, if a given domain were to always use title="Send Email" for send email buttons, a browser extension could be written to detect that and respond to it.

You’re placing a lot of faith in the capacity of a (currently non-existent) AT vendor. Wouldn’t it be easier to create one extension that works across all sites for a core set of items?

It also puts a lot of responsibility on the user to know about different domains and be able to load different taxonomies, or even know what they are. (Not intending to insult an audience, we all know that many people used to think the web was the blue “e”, it’s a universal thing!).

Wouldn’t one core-set be better all-round?


> But perhaps another site could use aria-label="Send Mail" for ALL of its send email controls. We could then do the same. Sure, this does not accomplish much, however, it starts developers thinking about purpose, and how to consistently communicate it and what that means exactly.

This confounds the point of the SC though, if one site uses one thing for “send email”, and another uses a different (programmatically determined) term, how does a user-agent know what to do with it? How does the user know to switch taxonomy?

It would be like having different terms in ARIA for slider, how would a screenreader know what to do with a “sliderbar”, “rangebar”, or “valueselector”?


> Finally, there is a clear plan (as discussed on the call) that when the taxonomy is ready, that the AA requirement be removed completely, and the AAA requirement replace it at the AA level.

I’m on-board with that, I just think that the new AA SC should be for a small set of concrete terms that are easy to build into an extension and help people straight away.

The new AAA could talk about meta-data & vocabularies, and later replace the current AA when they are established. (And one of those should be the “accessibility preferences” spec.)


> The fact that they could use this, to satisfy the now more strict AA standard is VERY important.

Agreed, and the initial core-set of terms would not be changed later, it would be moved to the spec and expanded on.

Cheers,

-Alastair