E-mail List Archives
Thread: ARIA best practise with inserting aria attributes based upon a condition or being pre-populated.
Number of posts in this thread: 2 (In chronological order)
I have done some searching on the net and haven't found anything on this topic. I want to find out what is the best practise and if there is any technical documentation to support the approach which I have outlined below.
2. A aria-hidden="true" is added to an <div> depending if the content has been expanded or not. Rather than just using <div aria-hidden="false"> then changing the parameter.
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.
Any supporting documentation to support peoples views would be helpful.
Sean Murphy | Senior Digital System specialist (Accessibility)
Telstra Digital Channels | Digital Systems
Mobile: 0405 129 739 | Desk: (02) 9866-7917
Digital Systems Launch Page<https://confluence.in.telstra.com.au/display/DCSYS/Digital+Systems+-+Able+Home>
Accessibility Single source of Truth<https://confluence.in.telstra.com.au/display/DCSYS/Accessibility+Resources>
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.
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:
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:
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.
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