WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: ARIA best practise with inserting aria attributes based upon a condition or being pre-populated.

for

From: Patrick H. Lauke
Date: Nov 20, 2020 6:16PM

On 21/11/2020 00:50, Murphy, Sean wrote:
[...]
> These are just two examples to illustrate what I am referring too. Thus I wish to know if the correct behaviour should be:
>
> <input .... Aria-invalid="false" aria-required=true"> over <input .... Aria-required="true"> then adding the extra attributes.

It depends on the specific attributes. Check the ARIA spec for the
particular attribute and see if it has a "(default)" specified. Per
https://www.w3.org/TR/wai-aria-1.1/#state_prop_values the browser will
assume (and expose) this when the attribute is empty or left out
altogether. In the above example, there's no practical difference
between the two: the default for aria-invalid is "false", so even if you
omit the attribute completely, browsers will consistently expose it the
same way as if it were explicitly set to aria-invalid="false" in markup.
https://www.w3.org/TR/wai-aria-1.1/#aria-invalid
So it really makes no difference in these cases. If you're handling the
attribute dynamically, you can either have it there from the start, and
then dynamically flip it between false and true...or you can leave it
out at the start, only add the attribute when it's true, and then
completely remove the attribute again from the object when it's false.
It's all the same.


Now with some other attributes, the situation is different. Take for
instance aria-pressed https://www.w3.org/TR/wai-aria-1.1/#aria-pressed -
note that in the "Values" there it has "undefined (default)". This means
that when you have, say, a button that can be pressed, you can't just
leave out aria-pressed="false" and only inject
aria-pressed="true"...because not having aria-pressed present in the
first place will signal to the browser (and then expose via the
accessibility API) that the button is not a "pressable" toggle type
control. Taking a simple example:

<button>foo</button>
<button aria-pressed="false">bar</button>

Say the intent is that both these button are "pressable", and that when
pressed, they will both have aria-pressed="true", but the first one
completely omits the attribute to begin with. browser/AT will not
announce the first button like that in any special way, give any
indication that it's pressable/toggleable. Taking Chrome/NVDA as an
example, the output for these when they receive focus:

foo button
bar toggle button not pressed

So, long story short: it depends(tm). Check the spec, and test, would be
my best advice. But for the cases (like the aria-invalid one you
mentioned) where there's a clearly defined default that kicks in even
when the attribute is absent altogether, it really makes no difference
how you implement that (explicitly in your markup/DOM, or omitting the
attribute altogether when it's in default value). It's then purely a
question of taste/programming style.

P
--
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke