Open feather opened 1 year ago
The fun starts when you then drag in the concept of "accessibility supported", which slams the onus back on the developer for using things that aren't properly supported (by whatever definition of "widely distributed" / "available" you go by https://www.w3.org/TR/WCAG21/#dfn-accessibility-supported)
Both 1.3.1 and 4.1.2 make some implied references to our jobs as authors (emphasis mine on the "can be" in 1.3.1 and "is available" in 4.1.2):
1.3.1: Information, structure, and relationships conveyed through presentation can be programmatically determined
4.1.2 For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.
My take: we need to do our job as authors; browsers/OS combinations and assistive technologies/APIs need to do their job as well -- they interpret the changes we make. I've also observed statements for years such as "this change should be automatically announced and it isn't, so it's a 4.1.2 issue"
If we set a widget to aria-expanded=true|false and a screen reader, for example, doesn't automatically announce that change, that seems to be a failing of the assistive technology, not the author. The author has both ensured that the presentational info/structure/relationships can be programmatically determined, and that state change is available to user agents and AT by setting the value programmatically.
If my interpretation is correct or incorrect, I'd like to propose some clarifying language in the non-normative documents to help people understand where their responsibilities end with respect to assistive technologies.