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.

________________________________