Comment on 1.3.4 (Identify Common Purposes) from G3ICT

[awkawk]

I am forwarding a comment from the President and Executive Director of the UN-organisation G3ict, see below.

Dear Susanna,

I wanted to follow-up on your question regarding section 1.3.4 “Identify Common Purpose” of the success criteria currently discussed in the context of WCAG 2.1.

From our perspective at G3ict, this is an extremely important success criterion in relation to the development of adaptive interfaces and assistive technology for persons with cognitive impairments. In particular, assistive interfaces may help distinguish main content from related information. This requirement allows tools to process the main information so that content is focused on, explained, translated to easy-to-read or supplemented with synonyms, images and illustrations.
We see several imperatives for the inclusion of this success criteria in relation to the trends in ICT accessibility and assistive technologies developments which we witness in the context of our global advocacy activities:

The high prevalence of cognitive disabilities among senior users prone to cognitive overload and memory losses necessitates using familiar interfaces, icons, and formats adapted to their cognitive abilities and preferences. Advanced intelligent interfaces providing automated adjustments to each user preferences are a fertile area of innovation and likely to succeed on a large scale. Aging patterns around the world, and the difficulties experienced by large public and private sector organizations such as e-government, financial services, e-commerce or transportation web services in serving seniors would seem to be strong considerations in that regard.

The global trend towards adopting smart interfaces and assistive technologies helping learners access relevant contents among the very large population of students in Special Education programs, a majority of whom experience cognitive or learning disabilities.

The potential to improve the experience of all users by leveraging cognitive accessibility features addressing widespread permanent or situational cognitive disabilities among the general population such as limited time or focus to comprehend information, memory loss, limited language abilities or attention deficit.

Given deadlines, I cannot stress enough in the limit of this short email how important it is for item 1.3.4 “Identify Common Purpose” to be included among testable criteria for the next generation of Web Accessibility Guidelines. Such criteria will help policy makers referencing WCAG to better factor in the needs of persons with cognitive disabilities which represent in most countries the largest segments of the population of persons with disabilities and remain very much underserved.

I hope that the above clarifies our position on this topic.

With best regards,

Axel

[awkawk]

Issue submitted after the comment deadline.

[clapierre]

For what it is worth (also after the comment deadline) Benetech and the DIAGRAM Center also feel that both
Success Criterion 1.3.4 Identify Common Purpose (AA)
Success Criterion 1.3.5 Contextual Information (AAA)

are crucial for Personalization and helping students with cognitive disabilities. The focus this year for the DIAGRAM Center is to help students with disabilities not traditionally associated with print disabilities and having both of these success criterion in WCAG goes a long way in helping us achieve our goals.
Thank you,
Charles

[johnfoliot]

I am anguished here... and those WG members who have worked on this SC closely already understand how important it is, and recognized how SC 1.3.4 really was the leading edge of the larger goal of content personalization. We've fought hard to retain this in its entirety, but with no mainstream applications currently consuming the type of metadata needed at the element level for this type of transformation capacity, we're between the proverbial rock and hard place. I tried to break that chicken and egg cycle, but did not succeed, as some WG members felt that using this SC to advance "experimentation" was overly heavy-handed. I really wish that G3ict, Funka, and or Benetech/DIAGRAM Center could help ($$$ and/or dev skills) with the development of those helper applications, as without them we'll not get the type of author support required from the content creators. There is no guarantee today that if we build it they will come... *What we need:* - Dedicated, internationalized software tools that allow for robust transformations based on element-level metadata - "Free" or low-cost Helper apps or browser extensions that offer rudimentary support (also helpful/required for testing purposes) - *Authoring tools* that aid content creators in adding this type of metadata at the authoring level (i.e. a WYSIWYG tool for those content creators who don't write "code", but still add *Web Content* via these editors - i.e. CMS/LMS systems and equiv.) Sadly, I had a proposal for a browser extension that would have supported the use of Schema.org ontology + Microdata annotation (very similar to the example solution provided by AUI Personalization <https://a11y-resources.com/developer/coga-personalisation>, which uses a non-w3c attribute that currently throws validation errors*), Lisa has a proof-of-concept application <https://github.com/ayelet-seeman/coga.personalisation> as part of the Draft Personalization Semantics spec that uses JSON and scripting to do page transformations, and I had had a series of constructive discussions at TPAC with WYSIWYG editor representatives around getting this type of authoring support into their tools (there was a general sense of positive feedback). David Wood (ex-Ephox AC Rep) had committed that if an extension to Tiny MCE was developed to provide this type of author support, that Ephox would add the 'extension' to their WYSIWYG editor and assume support from that time forward, but we didn't get there in time. Additionally, we've been dragged down rabbit holes around which ontology to use, how to map (namespacing is one solution, Microdata is another), a general sense of wanting this SC to be overly prescriptive (you can only do it this way using this taxonomy), a false narrative comparing this to ARIA in WCAG 2.0 (ARIA 1.0 was only finalized in 2014 <https://www.w3.org/TR/wai-aria-1.0/>, and had very little support in 2008 <https://webaim.org/blog/ie8-standards-compliance-and-aria/>, and was still not fully supported in 2010 <http://www.freedomscientific.com/downloads/JAWS/jaws12features>, contrary to assertions from some - and it was intended that all 2.0 SC could be met without the use of ARIA, even if ARIA made the solution super-easy) and/or is dependant on Specifications that simply are not ready <https://www.w3.org/TR/personalization-semantics-1.0/> and are at risk of not being so in time for 2.1's release in less than 6-months time. Simply put, we've run out of time for 2.1, and it is my sincere hope that we can resume this for 2.2. I can also appreciate the perspective of the European advocates and legislators here, but it would have been extremely useful if they had shown up earlier in the conversation, and had been able to materially help advance the technical ecosystem required to make this proposed SC a reality. Wishing and hoping alone does not a SC make... JF * *Error*: *Attribute *aui-action* not allowed on element *button <http://www.w3.org/html/wg/drafts/html/master/single-page.html#the-button-element>* at this point.* (source: https://validator.w3.org/nu/#textarea)

…

On Thu, Jan 18, 2018 at 10:04 AM, Charles LaPierre ***@***.*** > wrote: For what it is worth (also after the comment deadline) Benetech and the DIAGRAM Center also feel that both Success Criterion 1.3.4 Identify Common Purpose (AA) Success Criterion 1.3.5 Contextual Information (AAA) are crucial for Personalization and helping students with cognitive disabilities. The focus this year for the DIAGRAM Center is to help students with disabilities not traditionally associated with print disabilities and having both of these success criterion in WCAG goes a long way in helping us achieve our goals. Thank you, Charles — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#744 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABK-c5DlOAsjST5fkWp8QS2c54J1QCjpks5tL12VgaJpZM4Ri9cM> .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com Advancing the mission of digital accessibility and inclusion

[joshueoconnor]

<chair hat off, personal comment>

I really wish that G3ict, Funka, and or Benetech/DIAGRAM Center could help
($$$ and/or dev skills) with the development of those helper applications,
as without them we'll not get the type of author support required from the
content creators. There is no guarantee today that if we build it they
will come...

+1 to John. Many are saying this is really important etc and we need this etc, but as you rightly say the working group has practical needs for more energy and resources to make this happen. I totally empathise with your (and others) frustration here as I also see these SCS as being the cornerstone of a needed personalisation suite.

Nil deperandum however, as this will roll into 2.2 with many lessons learned.

[awkawk]

[Official WG Response]
Thank you for the comment. In the last round of updates the Working Group was able to reach consensus on the 1.3.4 SC for input controls only, whereas the previous version applied to all user interface components, including buttons and links. The Working Group received feedback expressing concerns that the previous language was relying on a schema that had not been rigorously developed, so the Working Group scaled the SC back to focus on the purposes that are in line with the HTML5 autofill detail token(https://www.w3.org/TR/html5/sec-forms.html#sec-autofill).

The ARIA Working group is continuing to work on Personalization Semantics (https://w3c.github.io/personalization-semantics/) and the AGWG anticipates that it will at some point be able to reference this work, but it is too early to do so in this specification.

[awkawk]

The WG decided on the above response, so we changed the text in the comment containing the proposed response to read "[Official WG Response]". Please confirm is you are satisfied with the response within 1 week. If we haven't heard a response in a week we will regard the resolution as satisfactory.