RE: With a AAA draft - was RE: Proposal for support personalization AA from John, Chris, Jan and myself

All,

 

This is very interesting….

 

I am thinking this may overlap with the proposed level AAA Accessibility Metadata SC we are working on with ePub.

 

Seems like we may need to collaborate….

 

​​​​​* katie *

 

Katie Haritos-Shea 
Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA)

 

Cell: 703-371-5545 |  <mailto:ryladog@gmail.com> ryladog@gmail.com | Oakton, VA |  <http://www.linkedin.com/in/katieharitosshea/> LinkedIn Profile | Office: 703-371-5545 |  <https://twitter.com/Ryladog> @ryladog

NOTE: The content of this email should be construed to always be an expression of my own personal independent opinion, unless I identify that I am speaking on behalf of Knowbility, as their AC Rep at the W3C - and - that my personal email never expresses the opinion of my employer, Deque Systems.

 

From: Lisa Seeman [mailto:lisa.seeman@zoho.com] 
Sent: Wednesday, July 19, 2017 3:00 PM
To: 'public-cognitive-a11y-tf' <public-cognitive-a11y-tf@w3.org>; 'W3c-Wai-Gl-Request@W3. Org' <w3c-wai-gl@w3.org>
Subject: With a AAA draft - was RE: Proposal for support personalization AA from John, Chris, Jan and myself

 

At AAA,  John and myself just drafted the following. It is very similar to the AA but extends and requires metadata or semantics

 

In content implemented using markup languages, the purpose and context of conventional controls and regions  can be consistently, programmatically determined and modified across a set of web pages through the use of metadata or semantics.

 

and we add to the definition of context  importance for simplification and position in a task – IE 

 

Contextual information:

Information which provides additional meaning for an object, such as the object’s purpose, level of importance for page comprehension and use, position in a process, relationship to other objects and processes, etc.

 

From: lisa.seeman [mailto:lisa.seeman@zoho.com] 
Sent: Wednesday, July 19, 2017 9:47 PM
To: public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org <mailto:public-cognitive-a11y-tf@w3.org> >; W3c-Wai-Gl-Request@W3. Org <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org> >
Subject: Proposal for support personlization AA from John, Chris, Jan and myself

 

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  <http://schema.org> 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> 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)