RE: H91 changes

*API inspection tools* are not just for developers, experienced evaluators use them as well….:)

 

​​​​​

 

 

 

* 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: Thursday, June 9, 2016 1:40 PM
To: WCAG <w3c-wai-gl@w3.org>
Subject: RE: H91 changes

 

*  The technique appears to be asking authors to check their forms using an accessibility API debugging tool at the platform level, whereas if HTML 5 is implemented properly, correct use of HTML form elements is enough to guarantee correct information at the accessibility API level. I think it’s sufficient for content authors to use the HTML elements correctly. The accessibility API mapping isn’t their responsibility. If it’s wrong, it’s a user agent bug.

 

I don’t think the technique is suggesting to use an API tool to catch issues with the browser.  The fact is that the accessible name calculation is complex and includes things like pseudo elements so it’s very tricky.  Using the API inspection tool is to help developers confirm that what they thought is the accessible name is really the accessible name – use of this is very important.  They don’t have to use just an API inspection tool though as there are alternatives that do parse the HTML for you.  These include Chrome’s Accessibility Developer Tools and Bryan Garaventa’s Visual ARIA bookmarklet.

 

http://whatsock.com/training/matrices/visual-aria.htm

 

Jonathan

 

Jonathan Avila

Chief Accessibility Officer

SSB BART Group 

jon.avila@ssbbartgroup.com <mailto: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: White, Jason J [mailto:jjwhite@ets.org] 
Sent: Wednesday, June 08, 2016 7:27 PM
To: Andrew Kirkpatrick; Greg Lowney
Cc: WCAG
Subject: RE: H91 changes

 

 

 

From: Andrew Kirkpatrick [mailto:akirkpat@adobe.com] 
Sent: Wednesday, June 8, 2016 5:20 PM

Jason, I don’t think that is entirely accurate.  The name, value, and state are determined by HTML, not by the operating system. The mapping guide does also include ARIA and the focus of this technique is to rely on what HTML provides directly and allow the aria techniques to cover aria.  The guide does set out to do this for the role, I agree.  We aren’t setting out to make our own version of the mapping guide so we are planning for now to change the procedure so that instead of saying what it currently does:

 

"For each instance of links and form elements, check that the name, value, and state are specified as indicated in the table above."

 

The new procedure indicates that there are platform-specific roles to pay attention to, as follows:

 

"Check the source code and verify that a platform role equivalent to the role indicated in the table is used"

 

The roles indicated in the second column of the table are not ARIA roles. There are no roles named, for example, “push button” and “editable text” in ARIA. Nor does the table indicate that it corresponds to any particular platform.

 

The correct information for HTML elements (ARIA roles where they exist, and platform-specific roles where there is no corresponding ARIA role) can be found in the Mapping Guide document at

https://www.w3.org/TR/html-aam-1.0/

 

I would be surprised if you couldn’t make a non-normative reference to the above as work in progress (updating it at Candidate Recommendation time, or even at Recommendation). Techniques are non-normative, after all.

 

My question to you is going to be “can you live with the H91 technique as proposed? (meaning with the table, and not referencing the not-final mapping document)”

 

The technique appears to be asking authors to check their forms using an accessibility API debugging tool at the platform level, whereas if HTML 5 is implemented properly, correct use of HTML form elements is enough to guarantee correct information at the accessibility API level. I think it’s sufficient for content authors to use the HTML elements correctly. The accessibility API mapping isn’t their responsibility. If it’s wrong, it’s a user agent bug.

 

I find this technique terribly confusing for all of the above reasons. If the point is, “use HTML form controls correctly”, then it should say so and stop there. I can’t live with it unless there is significant clarification, or a good reason to conclude that it’s correct after all and that I’m misinterpreting it.

 

 

  _____  

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.

 

Thank you for your compliance.

  _____