Re: working on the definitions for support personliazion

Just to clarify - I was just getting started on some of the definitions. It is not intended to be the full set.

Also, you pick the token that best matches your field. If you have one  field for the name, then you use the "name" field. If you have a separate field for  the honorific-prefix, then on that field you would use that token.

All the best

Lisa Seeman

LinkedIn, Twitter





---- On Fri, 28 Jul 2017 18:04:15 +0300 John Foliot<john.foliot@deque.com> wrote ---- 

> AC: Yes, but to overcome (mostly John’s) objection the items (names) need to be in a normative part of WCAG, e.g. the definition.


Erm... I don't recall specifically saying that. In fact, I've argued that for *today* (aka 2.1), providing >> Something/Anything << to address the user-need is better than nothing. (Thus a "prose" or localized string that provides additional assistance to the end user, applied to key page controls/inputs, is better than saying nothing at all.) 


It is far from perfect, as it does not address the needs of *all* cognitively-impacted users, but it does help some of those users, and it helps us underscore the importance of the need. By emerging as an AA SC in 2.1 - and, as we build out Success Techniques - it allows us to bring forward COGA Semantics (the spec), in very much the same way that we established conditions in WCAG 2.0 that did not *mandate* the use of ARIA, but made using ARIA the "duh, no kidding" solution as support for ARIA hardened and gained more traction.


Lisa / COGA TF came forward with a list of 75 (now apparently whittled down to 35 (?) - apologies as I am off-site this week) of key controls and inputs that would be applicable in this SC.


I do however agree that posting the list of those key controls/inputs MUST be included in the SC as a normative part of the SC, so that we have a 'list' to measure success/failure against.


JF


On Fri, Jul 28, 2017 at 9:09 AM, Alastair Campbell <acampbell@nomensa.com> wrote:
    
  From: Alastair Campbell  
 The problem is that the HTML5 list are tokens for attributes, not human readable names…
  
 [Jason] 
 All the proposal states is that the name can be programmatically determined, so a browser extension or other assistive technology can simply maintain an HTML5 token to localized name hash table for this purpose, and look up the name from the token.
 
  
 AC: Yes, but to overcome (mostly John’s) objection the items (names) need to be in a normative part of WCAG, e.g. the definition.
  
 Do you think we can use token/name pairs? E.g. 
 Full name (‘name’), Prefix or title (‘honorific-prefix’), Etc.
  
 And allow either value to be used?
  
 Cheers,
  
 -Alastair
  
  
  
 
 
 




-- 
John Foliot


Principal Accessibility Strategist

Deque Systems Inc.

john.foliot@deque.com



Advancing the mission of digital accessibility and inclusion