RE: Question: testing for non-unique id values SC 4.1.1 - Suggested New 4.1.1-ish SC

Jon,

 

I agree with you here. And this is where we have an opportunity in 2.1 to clarify for newer technologies that 4.1.1, or something like it, goes beyond HTML, if/when Incorrect, Broken, Inappropriate or Non-conforming (to its Spec) coded content.

 

This ability to improve what we know doesn’t really work well enough anymore – is one of the promises of WCAG 2.1.

 

In that vein, let do what David suggested and try to craft the improved language.

 

Here is my first stab at it…..

 

For demonstration purposes I will call the suggested SC 4.1.3: Compatible Parsing

 

(For Reference: Guideline 4.1 Compatible: Maximize compatibility with current and future user agents, including assistive technologies.)

 

4.1.3: Compatible Parsing:  When using web technologies content shall be coded according to their specifications where it is relevant to W3C accessibility specifications,  and user agents (including assistive technologies), to prevent mistakes/errors that affect assistive technology rendering of such content.

Note: Elements and component that are missing start and end tags or other critical characters in their formation, such as a closing angle bracket or a mismatched attribute value quotation mark are not coded according to specification.

 

The raltionale for this is to prevent Incorrect, Broken, Inappropriate or Non-conforming (to its Spec) coded content that affect AT.

 

 

 

* 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

 

From: Jonathan Avila [mailto:jon.avila@ssbbartgroup.com] 
Sent: Friday, September 30, 2016 9:38 AM
To: w3c-wai-gl@w3.org
Subject: RE: Question: testing for non-unique id values SC 4.1.1

 

*  It doesn’t seem to be a stretch to count JavaScript created markup or DOM manipulation as part of “markup languages”.

 

I agree. I believe the intent of that clause was to specify which technologies were in or out and not to say that DOM manipulation wasn’t covered.   I agree some things likely won’t be an issue in situations where content is added to the DOM dynamically but the SC would still apply IMO.

 

*  If the APIs are the official way to do things, the usefulness of 4.1.1 has reduced as anything the browsers don’t interpret should be apparent to everyone, not just people using AT.

 

I disagree because the visual rendering engine of the browser is likely separate from the DOM to accessibility API bridge and the accessibility API is likely to contain issues that aren’t rutinely found by the browser QA teams.  Unless the browsers start implementing some sort of accessibility test harness and really be looking for them.  The API is also susceptable to issues IMO when it’s built/updated based on bad structure.  How does the DOM to API bridge handle bad markup and what decisions does it make in order to compenstate for incorrect markup/DOM structure?

 

Jonathan Avila

Chief Accessibility Officer

SSB BART Group 

 <mailto:jon.avila@ssbbartgroup.com> jon.avila@ssbbartgroup.com

703.637.8957 (Office)

 

Visit us online:  <http://www.ssbbartgroup.com/> Website |  <https://twitter.com/SSBBARTGroup> Twitter |  <https://www.facebook.com/ssbbartgroup> Facebook |  <https://www.linkedin.com/company/355266?trk=tyah> Linkedin |  <http://www.ssbbartgroup.com/blog/> Blog

 <http://www.ssbbartgroup.com/webinars/> Check out our Digital Accessibility Webinars!

 

From: Alastair Campbell [mailto:acampbell@nomensa.com] 
Sent: Friday, September 30, 2016 4:03 AM
To: w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org> 
Subject: Re: Question: testing for non-unique id values SC 4.1.1

 

Andrew asked:

>  If I implement content using javascript to create a useful DOM tree, am I using markup?  

 

That’s a good point, and I would hope the answer is yes otherwise there is a whole category of websites not covered. (Assuming we want any to be covered by 4.1.1, the answer should be yes.)

 

It doesn’t seem to be a stretch to count JavaScript created markup or DOM manipulation as part of “markup languages”.

 

I think there has been a trend in recent years for AT to use the accessibility APIs rather than do their own interpretation. Jaws was the obvious one that did its own interpretation but I think it is using the APIs now… Can anyone confirm? Are there others that do their own interpretation?

 

If the APIs are the official way to do things, the usefulness of 4.1.1 has reduced as anything the browsers don’t interpret should be apparent to everyone, not just people using AT.

 

 

> Also, what is “markup content”?  :)

 

You (probably) jest, but “markup” does appear to be an omission from the WCAG 2 glossary!

 

-Alastair