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

> I think the AA requirement very specifically doesn't achieve much, but
the few things it does achieve are profound.  There were two key buzzwords
from the call today as they relate to cognitive disabilities, "purpose" and
"consistency". That some form of consistency is maintained in identifying
the purpose of a control is important, even if in the current state of the
web, this can't always be seen by the user without the help of some form of
AT.

I don't think "consistency" is a new concept in 2.1.

3.2.4 Consistent Identification: Components that have the same
functionality within a set of Web pages are identified consistently. (Level
AA)
 ​
​In this case "identification" is used instead of "purpose"​.  At the very
least there is
​so much
 overlap, that they would probably have to be merged after August.

See the understanding to see the similarities further:
https://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-consistent-functionality.html

Combine that with the SC

3.3.2 Labels or Instructions: Labels or instructions are provided when
content requires user input. (Level A)
​
The understanding is here:
https://www.w3.org/TR/UNDERSTANDING-WCAG20/minimize-error-cues.html​

​These two together seem to cover off most of this new AA SC.

I think that we should work any existing requirements in the AA proposal
into these two SCs. Surely Instructions and labels could provide the
purpose of the user interface components at least in many situations.

I think the new SC should be ALL about a short list of COGA semantics and
identification of situations where the ACCNAME, ACCDESCRIPTION, ROLE,
VALUE, or STATE. are sufficient in providing the purpose, and leaving it
for the plugins to figure out the purpose if it sees keywords in those
buckets. The requirement might be that certain keywords are used in those
buckets.

I personally think I have to spend some time with the COGA Personalization
spec to better understand situations where the purpose can be **implicitly
** provided by the ACCNAME, ACCDESCRIPTION, ROLE, VALUE, or STATE, (to be
discovered by the Plugins) and where it needs to be **explicitly provided**
using COGA semantics (Also discovered by the plugins)

I think we could put this at AA with an "at risk" marker, that it may be
moved to AAA or removed depending on developments with COGA, browsers and
plugins over the next 6 months. At AAA there could be more requirements
added.

I'd also like to talk with the IBM decision makers to understand their
reasons for not proceeding with the COGA semantics. If it is that there is
no WCAG requirement then we can provide that. But if it is because close
investigation revealed problems with implementation, and execution etc., I
think that is important to know.

​

​


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 Wed, Jul 19, 2017 at 11:08 PM, Chris McMeeking <chris.mcmeeking@deque.com
> wrote:

> Alastair, I don't believe John's comment intended to say "No Accessible
> Name Cannot Be", but rather that it is one of many potential ways
> developers could use to satisfy this.
>
> I think the AA requirement very specifically doesn't achieve much, but the
> few things it does achieve are profound.  There were two key buzzwords from
> the call today as they relate to cognitive disabilities, "purpose" and
> "consistency". That some form of consistency is maintained in identifying
> the purpose of a control is important, even if in the current state of the
> web, this can't always be seen by the user without the help of some form of
> AT.
>
> The fact that the AA requirement does so without requiring a "taxonomy" is
> important, because there is no taxonomy. Dozens of taxonomies is not a
> taxonomy. This version of the requirement acknowledges that, and encourages
> I suppose "domains" to use their own consistent methods, WHATEVER those may
> be. 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. 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.
>
> 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.  Forward thinking organizations
> that have done the AA level requirement correctly WOULD NOT have to modify
> their entire website one property at a time. Rather they could take
> advantage of this consistent identification they have been using as a
> result of the current AA requirement to write a srcipt that says:
>
> forAll(alt="Go Home").apply(coga-purpose="home");  //My appologies for
> the pseudo code and butchering of "Coga" this is purely hypothetical
> example!!!
>
> The fact that they could use this, to satisfy the now more strict AA
> standard is VERY important. The AA standard begins the process of
> developers thinking about the consistency of identifying purpose, and the
> ones that want to do it right will start working and helping develop and
> testing standards. With the AAA requirement waiting in the wings, more will
> see the value of being able to do this consistently across the entire web,
> EVEN IF perhaps the AA standard doesn't have immediate impact, it will
> drive the impact of the AAA requirement much more quickly than without it.
> With the proper techniques built around the two criteria together, we will
> minimize the short term economic impact on organizations, by giving them
> time to think about this consistency in a MUCH SIMPLER sandbox and yes
> admittedly, it is not as helpful as we may have hoped. But, the folks from
> the Coga task force on the call seemed quite happy with it.
>
> Chris
>
> On Wed, Jul 19, 2017 at 6:57 PM, Alastair Campbell <acampbell@nomensa.com>
> wrote:
>
>> Hi John,
>>
>>
>>
>> I like the term “purpose” for this, but I’m confused as to why
>> “consistently” and “across a set of web pages” have been added?
>>
>>
>>
>> If the point is to identify conventional controls across **websites**,
>> each site having its own version is not desirable.
>>
>>
>>
>> The changes imply that it will be different on different sites, so how
>> does a user agent know what to do with these programmatically determined
>> controls?
>>
>>
>>
>> In the same way that name/role/value needs ARIA to specify things
>> *beyond* native semantics, there needs to be a central / standardised
>> way of saying what the purpose is.
>>
>>
>>
>> I’m missing what it achieves at AA at the moment.
>>
>>
>>
>> -Alastair
>>
>>
>>
>>
>>
>>
>>
>> *From:* John Foliot [mailto:john.foliot@deque.com]
>>
>>
>>
>>
>> *@(AA): In content implemented using markup languages, the purpose of
>> conventional controls[1] can be consistently, programmatically determined
>> across a set of web pages. *
>>
>>
>>
>> *@(AAA):*
>>
>> *In content implemented using markup languages, the purpose of
>> conventional controls[1] can be consistently, programmatically
>> determined and modified across a set of web pages through the use of
>> metadata or semantics. *
>>
>>
>>
>>
>>
>
>