Re: working on the definitions for support personliazion

Hey Alastair,

As I am off-site at our company all-hands, I can't apply my full thought to
this at this time (I need to stay focused on what's happening here in
real-time).

However as a general statement, at the AA level I don't think introducing
*new* semantic constructs should be part of the SC activity. Instead the
suggestion is that we essentially mandate the use of existing semantic
constructs (which at it's weakest could be expressed as <[element]"
title="this is what you need to do">) to deliver the partial solution of
the larger need/desire that would be addressed in the AAA SC.

JF

On Fri, Jul 28, 2017 at 11:08 AM, Alastair Campbell <acampbell@nomensa.com>
wrote:

> > 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 think the HTML list Lisa was comparing against was just for form inputs,
> so that doesn’t cover the nav or button controls that are also in the
> definition.
>
>
>
> > 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.
>
>
>
> Sorry for misquoting, but that is the bit I was getting at.
>
>
>
> Would it be ok to have that as name/value pairs?
>
> E.g. Prefix or title (‘honorific-prefix’).
>
>
>
> Where the ‘name’ is what’s in the current definition, and the token in
> brackets is copied in from the HTML spec when possible, or created for this
> purpose for the others.
>
>
>
> Cheers,
>
>
>
> -Alastair
>
>
>



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

Advancing the mission of digital accessibility and inclusion