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

Hi David,

No, I don't believe it's the really the accessible name that is required
here, although that is part of the puzzle.

Take a basic submit button:

What we can determine programmatically today:

Property: Button

State: 'False' (see:
https://www.w3.org/TR/wai-aria/states_and_properties#aria-pressed)

Role: Submit

What is missing?

Purpose: Clicking on this button sends your form to the company. (This is a
simplification)


Techniques could include: @value (the content author *could* provide all of
the information in the button itself: <input type="submit" value'"Clicking
on this button sends your form to the company.">), @title (yech, but
valid), @aria-describedby, coga-moreinfo (which according to the draft coga
spec takes a string value), and perhaps others, all to achieve the AA, but
at AAA it would *specifically* require the use of a publicly available,
fixed taxonomy (for disambiguation and the ability to, for example, change
text to icons).

So, in other words, it isn't just "This is David", but rather "David is
going to help you with this Success Criteria".

Make sense?

JF

On Wed, Jul 19, 2017 at 3:24 PM, David MacDonald <david100@sympatico.ca>
wrote:

> I'm guessing that the "purpose" of most of the items in question can be
> provided by the ACCESSIBLENAME although sometimes extra information may be
> needed. I would also call this "metadata".
>
> Any plugin that identifies attributes and personalizes should
> automatically sniff the ACCESSIBLENAME, ACCDESCRIPTION, ROLE, VALUE, and
> STATE and if those provide the purpose of the control then map it to the
> corresponding "purpose" bucket.
>
> For instance, if the visible labels on controls (ACCNAME) contain the
> purpose (listed below) then that should provide the purpose for
> customization plugins without redundantly providing coga-personalization or
> aria-describedbya title attribute etc.
>
> *From inputs: *
>
>    - name (corresponds to both first and family),
>    - first name,
>    - family name,
>    - initial,
>    - phone (corresponds to a user phone number),
>    - cell phone,
>    - address 1,
>    - city,
>    - state,
>    - country,
>    - post code,
>    - credit card,
>    - credit card security code,
>    - dates: expiry date, birth date, today's date, date start, date end
>    - calendar data: day, *month, *year,
>
>
> *Buttons or controls (editing):*
>
>    - compose,
>    - delete,
>    - next,
>    - previous,
>    - submit,
>    - undo,
>    - cancel,
>    - buy,
>    - add label,
>    - move,
>    - view,
>    - save,
>    - send,
>    - received,
>    - sent,
>    - edit,
>    - reply,
>    - forward,
>    - my profile,
>    - upload,
>    - close,
>    - more,
>    - calendar,
>    - entry,
>    - expand,
>    - unexpanded,
>    - open,
>    - new,
>    - print,
>    - settings,
>    - mode,
>    - higher,
>    - lower.
>
>
> *Buttons or controls (navigation): *
>
>    - home,
>    - contact us,
>    - our phone,
>    - our email,
>    - site map,
>    - help,
>    - about us,
>    - terms,
>    - tools,
>    - comment,
>    - language,
>    - sign in,
>    - sign up,
>    - product,
>    - services,
>    - social,
>    - post,
>    - contact us,
>    - help,
>    - chat help
>
>
>
>
>
> Cheers,
> David MacDonald
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Tel:  613.235.4902 <(613)%20235-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 3:39 PM, Chris McMeeking <
> chris.mcmeeking@deque.com> wrote:
>
>> I think in the triple A criteria you can remove "across a set of
>> webpages". To me this was placed there to scope "consistently" as in the
>> "series of webpages" needs to identify the purpose of controls
>> "consistently". I think in the AAA case, we specifically don't want that,
>> and would want metadata to be scoped more broadlly (fixed taxonomy, not per
>> web page/series of web pages taxonomy). I'm also not sure what "and
>> modified" is getting at and agree as well. I propose the folloowing:
>>
>> *In content implemented using markup languages, the purpose of
>> conventional controls[1] can be consistently, programmatically
>> determined through the use of metadata.  *
>>
>>
>> On Wed, Jul 19, 2017 at 3:31 PM, lisa.seeman <lisa.seeman@zoho.com>
>> wrote:
>>
>>> hi Jason
>>>
>>> I agree that the AAA the word "modified" should be removed. The AAA
>>> might not be  quite finished yet.
>>> I am also happy with the "*user interface component" *change
>>>
>>> Any objections? Chris? John?
>>>
>>> All the best
>>>
>>> Lisa Seeman
>>>
>>> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter
>>> <https://twitter.com/SeemanLisa>
>>>
>>>
>>>
>>>
>>> ---- On Wed, 19 Jul 2017 22:24:11 +0300 * White<jjwhite@ets.org
>>> <jjwhite@ets.org>>* wrote ----
>>>
>>>
>>>
>>>
>>>
>>> *From:* John Foliot [mailto:john.foliot@deque.com]
>>> *Sent:* Wednesday, July 19, 2017 2:59 PM
>>>
>>>
>>> *@(AA): In content implemented using markup languages, the purpose of
>>> conventional controls[1] can be consistently, programmatically determined
>>> across a set of web pages.*
>>>
>>> *[Jason] By “consistently” do you mean by the same means, or something
>>> more? That is, are you trying to ensure that the same representation is
>>> used everywhere within a set of conforming pages, or is there more to it? I
>>> think clarification would be helpful either in the text of the proposal or
>>> in a definition.*
>>>
>>> *@(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. *
>>>
>>>
>>>
>>> *[Jason] I don’t know what “modifying” the purpose of a “conventional
>>> control” amounts to, or how to satisfy this aspect of the proposal. If you
>>> mean that the state or value of the conventional control can be modified
>>> (i.e., “programmatically set”), then that’s already in 4.1.2, indeed for
>>> all user interface components rather than just for those you list. If you
>>> really intend modification of the purpose, then it isn’t clear what that
>>> would entail. I suggest dropping the “and modified” provision, or
>>> clarifying and rewriting it.*
>>>
>>> *Also, consider whether to use the term “user interface component”
>>> (already in WCAG) rather than “control” in the proposal. Having two
>>> synonymous or almost synonymous terms in the document is only likely to be
>>> confusing.*
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> This e-mail and any files transmitted with it may contain privileged or
>>> confidential information. It is solely for use by the individual for whom
>>> it is intended, even if addressed incorrectly. If you received this e-mail
>>> in error, please notify the sender; do not disclose, copy, distribute, or
>>> take any action in reliance on the contents of this information; and delete
>>> it from your system. Any other use of this e-mail is prohibited.
>>>
>>> Thank you for your compliance.
>>> ------------------------------
>>>
>>>
>>>
>>>
>>
>


-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion