Categories
HTML Accessibility

short note: WCAG/ARIA – state of confusion

Dr Swallow slowly emerges from his sphere of knowledge to impart sage advice to the sphere of the other

WCAG 4.1.2 Name, Role, Value, states

states, properties, and values that can be set by the user can be programmatically set

Non-geek speak

If something a person does to a thing causes it to change then the change is reflected in the code

a person can

a person cannot (in general)

not user modifiable

If the value of property cannot be set by the user it is not covered by 4.1.2 Name, Role, Value (Level A). So when a testing tool or some titular authority figure states that a lack of an aria-controls attribute, for example,  is a failure of 4.1.2 it is wrong

Further listening
(for Hidde)

5 replies on “short note: WCAG/ARIA – state of confusion”

Wouldn’t a dialog that doesn’t announce its name (i.e. it doesn’t have a programmatically defined name) be a failure of 4.1.2? The item has no programmatically determinable name. Where else would it go – 1.3.1 because (in theory) the dialog has a visible title/name? The text for 4.1.2 mentions no programmatically determined name, role, value in addition to user state changes.

Hi Becky,

Wouldn’t a dialog that doesn’t announce its name (i.e. it doesn’t have a programmatically defined name) be a failure of 4.1.2?

Yes, what I have said is not about role or name its about states/properties

I’ve always found aria-readonly a curious semi-exception. It’s important to communicate readonly properties, but they cannot be set by the user so they can’t be failed under 4.1.2.
Then again you can fail things like readonly or required under 3.3.2 (the language isn’t super clear on this but I think it is a pretty logical interpretation.
And don’t get me started on the lack of AT support for aria-controls and aria-flowto. Jaws had a cool aria-fowto shortcut key actually but it was one of those hidden features.

But we can see why so many people make this mistake in understanding the clause in question. The wording is yet one more horrendous example of WCAG-speak that is quite simply illogical in what it says. The first question any reader will ask is, if values have been “set by the user” why would we want the system to “programmatically set” those values? That will change the value from what the user has just set, to something else, surely! And the glossary definition of “programmatically set” saying “set by software” (“set by software using methods that are supported by user agents, including assistive technologies”) in no way explains that illogicality. What the WCAG really means here is that, when the user sets a value, state or property, then that change is captured in the author’s coding – by using ARIA – (or in the browser’s data handling, in the case of values) so that it can be passed on to assistive technology.

The second question that will then occur to the reader is, what does “values that can be set by the user” mean anyway? Does clicking a button change its property or state? That is not so obvious. A highly experienced developer with a deep understanding of the way web coding works will understand that to be a yes, but non-technical readers (e.g. managers involved in IT) or even average, lesser experienced web developers won’t necessarily understand that implication of button clicks.

Unfortunately, the WCAG seems to follow the rule “never use two words where one word will do even if the two words would be clearer and easier to understand”! I have been arguing for years against just this kind of wording that only causes grief and misunderstanding. If 4.1.2 had been better worded in the first place we wouldn’t be needing to explain things by writing the kind of article that you had to write here! But it is a very useful article that hopefully clarifies 4.1.2 to people now, so, excellent.

Leave a Reply

Your email address will not be published. Required fields are marked *