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

Yes this is also my thinking on the issue. I think Lisa may have had
several hopes for the SC. Let me see if I can articulate them.

   1. Ensure a  "conventional name" is used across sites and across the web
   2. Ensure these can be programmatically determined to add symbols, and
   streamline content so stuff can be dropped off the page to simplify it.
   3. Add context when it is not obvious what the thing is or does. This
   could be prose and/or programmatic. This is a little ambiguous right now.

I think after August, we can offload some of this to 3.3.5 Context
help, 3.2.4 Consistent Identification, 3.3.2 Labels or Instructions, and
focus on the programmatically determinable part, which might even be merged
into 4.1.2 if something like programmatic "purpose" added to the list of
Name, Role, Value, State



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 Thu, Jul 20, 2017 at 6:08 PM, Alastair Campbell <acampbell@nomensa.com>
wrote:

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