Re: Accessibility Support - 4th option

Jon,
I agree with this, and while I see it as a subset of one of the three options it is worth calling out on its own. I also agree that this is how things work currently for most techniques.

The risk of this is greatest for new technologies. Much as with Flash in the past there might be assistive technology support that isn’t aligned with documented ways that accessibility information needs to be conveyed in a new technology. If a VR headset displays content per some specification and that specification includes how accessibility information is to be included and there are no assistive technologies that voice/render that content, how is that handled? I think that is a similar question to what you are asking in your last sentence for a new HTML feature, and it is where it gets hard to manage…

Thanks,
AWK

Andrew Kirkpatrick
Director, Accessibility
Adobe

akirkpat@adobe.com<mailto:akirkpat@adobe.com>
http://twitter.com/awkawk



From: Jonathan Avila <jon.avila@levelaccess.com>
Date: Wednesday, August 31, 2022 at 9:55 AM
To: WCAG <w3c-wai-gl@w3.org>
Subject: Accessibility Support - 4th option
Resent-From: WCAG <w3c-wai-gl@w3.org>
Resent-Date: Wednesday, August 31, 2022 at 9:54 AM


EXTERNAL: Use caution when clicking on links or opening attachments.


I’d like to propose to the group that we consider a 4th option to the 3 options outlined by the Accessibility Supported group which is discussing handling accessibility support in WCAG 3.0.

An option to consider is

  *   Allow authors to use standard documented platform and specification techniques without having to validate accessibility support

     *   For example, use of alt text on images, ARIA according to the specification, HTML attributes used according to the specification and align with documentation such as HTML API Mappings 1.0, etc.
     *   When non-standard methods are used then those methods would need to be accessiblity supported
This allows organizations to use standard documented known methods without having to worry about compatibility while at the same time allowing for flexibility to use other things as long as they work with a combination of user agents, assistive technologies, etc.  This is somewhat how things work today from a de facto standpoint.

For example, you could use autocomplete values to communicate input purpose without having to test for accessibility support.  But if you wanted to use another method such as metadata that was not documented by the specification then you would have to show it is accessiblity supported.

The challenge with this approach is who determines which platform or specification level documentation is allowed and how new specification features are adopted by assistive technology.  For example, HTML could add a new feature that is not yet supported by assistive technology.

Best Regards,

Jonathan