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

Thanks Jason,

I had an idea after the call that might be another path, riffing on some of David’s comments, my last ditch attempt!

(Um, having written this email and looked back, it is almost exactly what David suggested yesterday, but I’m adding some SC text to the mix and removing the reliance on metadata.)

The key part is that often the (acc)name is suitable for common controls, in fact, that could be a way to fulfil the criteria, and the metadata is another way.

“Purpose of controls: In content implemented using mark-up languages, the conventional name of common controls can be programmatically determined.”

Definitions:

  *   Common controls is essentially Lisa’s list.
  *   Conventional name, a name for the common control available in a public vocabulary (or taxonomy if you prefer).

I’m not wedded to the term “conventional name”, but I think the concept has legs.

The list of common controls should *be* an available public vocabulary, but it isn’t restricted to that.

For example, if the link to the homepage is:
<a href=”/”>Home</a>

The accessible name matches the conventional name, job done.

If the link to the homepage is not the same, then add some metadata according to the technique (to be written):
<a href=”/” pref-destination=”Home”>MySite.com</a>

So, like ARIA, you don’t need to use the attributes to fulfil the guideline.
Also like ARIA, you will want to use the attributes to fulfil the guideline.

What I’m really not looking forward to doing (or explaining to others) is something like:
<a href=”/”>Home</a>
<p id=”homedesc” class=”hidden”>Press this link to go to the homepage</p>

That approach has value for some controls, but I think it is actively harmful to common controls.

There are some technical details (I18N, spaces in values?), BUT my primary question now is:

Does this general approach overcome the objections on (the principle of) using metadata at AA?

It doesn’t conflict with some of the other ideas such as adjusting WCAG2 SCs to cover some of the other use-cases, and a stronger requirement at AAA.

Cheers,

-Alastair

PS. I think there would be real value in modularising the coga-personalisation spec, with this area as the first module. Also, generalising it to accessibility preferences (or just preferences), so that other disability-types get some coverage.

PPS. I looks like most of the common controls would work as single-name items without spaces?