E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 2 (In chronological order)

From: Murphy, Sean
Date: Fri, Nov 20 2020 5:50PM
Subject: ARIA best practise with inserting aria attributes based upon a condition or being pre-populated.
No previous message | Next message →

Team,

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.


1. If you have an element. Depending on a codition of what the user has done on the web site. Some aria attributes are added to the tag via javascript. For example: An edit field contains the aria-required attribute. The aria-invalid is added to the <input> field after the field fails the validation javascript. This edit field does not have any required by design.
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.

Regards
Sean Murphy

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>

From: Patrick H. Lauke
Date: Fri, Nov 20 2020 6:16PM
Subject: Re: ARIA best practise with inserting aria attributes based upon a condition or being pre-populated.
← Previous message | No next message

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