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

To tag onto Lisa's email...

During our call today discussing the Personalization SC, we (at least *I*)
had an epiphany: What was being asked for (ultimately) was a fourth piece
of data (outside of the 3 that ARIA provides) - "Purpose". ARIA today
allows us to programmatically define Role, State and Property, but not
"Purpose", and without that piece of critical information, it makes it
harder for 'transformation' as well as comprehension for some users.

Based upon that insight, we came up with essentially 2 new, tightly related
SC (n the same way that SC 3.3.3 and 3.3.6 are tightly related):


*@(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.  *


The key was also thinking about techniques and available techniques today.

The AA SC can be accomplished using either native HTML5 semantics (example:
<input type="tel">), sometimes with ARIA, and other times with other
existing semantic constructs (example Microformats: <time class="dt-start"
datetime="2013-06-30 12:00">30<sup>th</sup> June 2013, 12:00</time> to <time
class="dt-end" datetime="2013-06-30 18:00">18:00</time>) - but that it can
all be achieved TODAY.

The 2 critical requirements are "Purpose" and "Consistency".

In fact, from a Technique's perspective we'd prefer the use of fixed
taxonomies as being the most granular (and thus actionable) Technique, but
we would only mandate that at a AAA level today, in part because COGA
semantics (the prefered taxonomy, but we MUST leave open the door for
others) is still not a W3C Recommendation.

However, because the AA SC does not require a fixed taxonomy, it may mean
that some page transformations will not be achievable today (although
advances in AI may prove me wrong as well, and content authors are free to
create their own methods of providing 'transformations'), but providing
"Purpose" to the end user, even if it is in prose, is a critical step in
the right direction.

And as noted on that call, the advancement of both of these SC
simultaneously also provides us with a huge "teachable" moment, with some
developers quickly grasping that while the AAA requirement seems "harder",
in actual fact the Techniques to meet AAA (which would also satisfy AA) are
in fact the better development path anyway, so... (so, hopefully there will
be a quicker adoption).

We also agreed on the call that the current list of Conventional Controls
will need to be explicitly defined in WCAG 2.1, and the following is the
first draft list (with a desire / understanding that it may be reduced by
the larger group - in fact it is believed that is probably necessary)


[1] Draft list of Conventional Controls:
(note: we may be able to whittle this list down a bit - for a larger group
discussion)

*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.


And so... poke away. What does the wider group think of this?

JF

On Wed, Jul 19, 2017 at 1:47 PM, lisa.seeman <lisa.seeman@zoho.com> wrote:

> Hi Folks,
>
> John, Chris, Jan and myself are all happy with the proposal for support
> personlization.
>
> *In content implemented using markup languages, the purpose of
> conventional controls can be consistently, programmatically determined
> across a set of web pages.  (AA)*
>
> We also would like the metadata SC to be included at AAA. Techniques using
> coga semantics , microdata etc would conform at both AA and AAA level. A
> techniques using a linked to description of the context would only conform
> at AA and may be depreciated when the support for COGA semantics is more
> robust.
>
> Please let us know if there are other concerns.
>
> The current definition list for conventional controls will probably need
> some tweaking but we are all  happy to leave that until after august and we
> get public comment on it. The current list is:
>
> Conventional controls for form  fields: 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,
> phone, credit card, expiry, birth date, day, *month *year, expiry date,
> today's date, credit card code, date start, date end.
> Conventional controls for buttons or controls: 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.
> Conventional controls for links: home, contact us, our phone, our email,
> site map, help, about us, terms, tools, comment, language, sign in, sign
> up, product, services, social, post, contactus, help, chat help,
>
>
> ---
> Full notes from the meeting (this also explains the reasoning)
>
> ·         John:  You talk about “contextual information,” is this really
> a labeling issue?
>
> ·         Lisa:  It’s not labeling – we need a taxonomy – we need to know
> what the thing is.  Not from a button perspective – we know it’s a button
> because of the ARIA role, but we need to know that it’s the “Send Button.”
>
> ·         Chris:  Is it that there’s an interpretation of current success
> criteria because someone is not using current semantics properly; Why is
> send a bad example?
>
> ·         Lisa:  Why are you heated over choosing an example?
>
> ·         Chris:  I think you believe send is a bad example because there
> are taxonomies that are available for things like “send” button
>
> ·         Lisa:  Let’s take an example of
>
> ·         John:  right now with ARIA, we can do role, state and property,
> but what we are missing is purpose
>
> ·         Chris: ARIA lacks purpose and the contextual information we
> need is not something that a user agent could infer from anything else?
>
> ·         John:  If what we are looking for is a method to define a
> purpose, then it seems to me that we can do this two ways:
>
> ·         Fixed taxonomy – most accurate
>
> ·         Less accurate, but still provide information through prose
>
> ·         Lisa:  the only way we could enforce this would be to impose
> vocabulary on the free-flowing text
>
> ·         John:  then it would have to be a AAA
>
> ·         Lisa:  then that doesn’t really work
>
> ·         … having worked in this field for a while, you are really only
> able to get 80% accuracy
>
> ·         John:  One of the things I am hearing here is:
>
> o   Ability to transform the home button into a symbol (content
> transformation)
>
> o   Under the larger umbrella of personalization, how do I simplify the
> page (e.g. remove flashing banner adds, and/or using smaller devices) – I
> think 1.3.1 and 4.1.2 alludes to this, but neither of them actually says
> that you have to submit strong semantic on your website.
>
> ·         Lisa – I think we should submit it at risk, define the risk,
> and then people can decide; if we say that this is the one or two things we
> are missing, then those team know that they have 3 months to build it; IBM
> backed out, but if they think that because of the group, this will get
> passed in 3 months, then people would develop the tech necessary
>
> ·         These are patent actions if we get these tools built that are
> identified as being at risk
>
> ·         John:  I don’t share that opinion.  In the interest of
> scalability, it would have to be a AAA – we can’t go out and tell clients
> that they have to do this tomorrow.
>
> ·         Chris – If you hand things to developers (standards documents,
> metadata, etc.) that is not fleshed out, there is going to be an inherent
> tendency for multiple standards will develop; it would be better to have
> one, solid standard – to take the time and to not have conflicting
> solutions.
>
> ·         John:  We have a lot of metadata systems out there, but
> schema.org seems to be the most widely used; microformats and microdata
> are supported, but not really used
>
> ·         John:  we don’t have a requirement to use ARIA
>
> ·         Lisa:  Correct, but even with the mess, it’s still better than
> having nothing
>
> ·         John:  everything in WCAG 2.0 can be met without ARIA
>
> ·         Lisa:  does not agree; there was a lot of content that you
> can’t do without ARIA
>
> ·         John:  are you good with the notion of advancing 2 SCs?
>
> ·         Lisa: yes
>
> ·         John:  what we need is purpose; Lisa is prepared to take a
> fairly broad and usely defined scope for AA you have to do something and
> will you accept metadata at AAA?  If I can programmatically determine
> (aria-describedby) what happens when a user presses a button.
>
> ·         Lisa:  what is the problem with the current wording?
>
> ·         John:  if symbols are not available, then what happens?  What
> they can do is make sure that all controls on the page are linked to
> SOMETHING that provides the purpose – and then the problem is that we need
> a way to expose the purpose of the control to the user – it won’t address
> everyone’s needs, but it will expose it to a lot of users; can we leverage
> existing semantics for AA to provide purpose;
>
> ·         Lisa:  would we deprecate that technique at some point?
>
> ·         Chris/John – yes
>
> ·         John:  Over time, after the semantics are more widely used, the
> AAA technique would become AA – the use of metadata would be ideal
>
> ·         Chris:  If we word the AA requirement – we are missing the
> taxonomy; if we phrase the AA requirement in a way that would only require
> consistency – maybe they create their own internal taxonomy and they can
> identify which button will always have this purpose, regardless of what it
> does;
>
> ·         John – how would you expose it to the end user?
>
> ·         Chris:  let’s say we have the gmail app and you need to go back
> to your inbox and it says inbox every time, no matter what page it’s on –
> and that is the requirement – consistently; if this is updated, then a
> script could be written
>
> ·         John – we have to keep a separation between requirements and
> techniques – this notion of purpose is important; there are multiple
> techniques – you could create your own taxonomy, but that doesn’t solved
> the site without creating a plugin for the browser
>
> ·         Chris – I am not talking about creating a taxonomy, but
> something analogous to taxonomy – all I am saying is that a link on the
> page shares a common attribute – it doesn’t matter what it is
>
> ·         Lisa; then 2.2.4 – consistent identification
>
> ·         John:  at the end of the day, if you click on something that
> takes you somewhere else, then it’s going to be a link or a button.
>
> ·         John – AA – a consistent mechanism is available that defines
> the purpose of the control or the elements;
>
> ·         Lisa: In content implemented using markup languages, for
> navigational elements form elements and interactive controls, the purpose
> of  conventional elements can be consistently  programmatically determined
> across a set of web pages.
>
> ·         John we need to have no more than 12-14 conventional elements
> at AA
>
> ·         John – I am not an international expert, but we need to be
> sensitive to that
>
> ·         Lisa – here are the conventional elements we have defined:
>
> ·         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, phone, credit card, expiry,
> birth date, day, *month *year, expiry date, today's date, credit card code,
> date start, date end.
>
> ·buttons or controls: 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.
>
> · home, contact us, our phone, our email, site map, help, about us,
> terms, tools, comment, language, sign in, sign up, product, services,
> social, post, contactus, help, chat help,
>
> ·(last think was links)
>
> ·         Chris – I like that this is forward compatible because you
> could write a script to update your site once the COGA taxonomy is
>
> ·         John: The Conventional Elements you have listed here seems a
> little heavy – perhaps we can whittle this down a bit – everyone pick three
> to remove, etc.
>
> ·         Chris – a lot of these things where the taxonomy of HTML 5
> already addresses
>
> ·         John – I am going through the list of controls and elements –
> date start and date end - if you go and look at
> http://microformats.org/wiki/h-event as an example of how to meet this at
> AA with an existing tool today
>
> ·         John – we just need to go through the list of conventional
> elements
>
> ·         Lisa – I am wondering if we can just whittle the list down
> after August – especially if the list can be commented on during the
> comments of the proposed criteria.
>
> ·         Chris:  Why do we need navigational, form elements and
> interactive controls – can we shorten that to interactive controls?
>
> ·         Lisa … the purpose of conventional, interactive elements can be
> consistently programmatically determined across a set of web pages
>
> ·         John – what about “controls” instead of elements?
>
> ·         John: the purpose of conventional, interactive controls can be
> consistently programmatically determined across a set of web pages
>
> ·         Chris – you could remove interactive
>
> ·         Chris: the purpose of conventional controls can be consistently
> programmatically determined across a set of web pages
>
> ·         Final suggestion from John:  In content implemented using
> markup languages, the purpose of   conventional interactive controls can be
> consistently, programmatically determined, across a set of web pages. (AA)
>
>
>
>
>


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

Advancing the mission of digital accessibility and inclusion