W3C home > Mailing lists > Public > public-pfwg@w3.org > October 2014

aria-hidden="true" revisited

From: Birkir Gunnarsson <birkir.gunnarsson@deque.com>
Date: Sat, 11 Oct 2014 22:57:04 -0400
To: "PF" <public-pfwg@w3.org>
Message-ID: <020001cfe5c8$35276d70$9f764850$@deque.com>
Greetings everyone

 

I know we have been discussing possible changes to the aria-hidden attribute
recently and I have to add a use case here, based on a lot of frustrations
in recent weeks.

In my work I repeatedly come across trouble with the well intended use of
aria-describedby for error messages.

 

The setup is simple (and I pointed this out in a post regarding
aria-errordescribedby earlier, but it also applies here).

 

People often hardcode error messages for form fields in the static html but
hide them using display: none.

Then they intend to make their forms super accessible and put
aria-describedby attributes on the form fields to associate them with the
error message.

They assume that when the error messages become visible, they will be
announced when assistive technology user puts focus on the invalid form
field(s).

 

The problem: display: none/visibility hidden does not hide content
associated with a field using aria-describedby. Its value will still be
included in the accessible name calculation for the field.

In fact the only way to hide it is not to use those attributes until the
error is visible, and dynamically add and remove them every time you show or
hide the messages.

 

User will always hear the error message and may think there are errors in
the form, even before he starts interacting with it the first time.

 

Code snipet (and yes, generally I would not use title attribute alone for
labeling an input field , I do this out of simplicity and laziness):

<span id="error1" style="display: none;">Error! First name cannot exceed 30
characters, complain to your parents and find something more suitable</span>

<input type="text" size="30" id="firstname" title="please enter your first
name" aria-describedby="error1">

 

The Javascript that validates the form will change "display: none" to
"display: block" if first name is longer than 30 characters.

 

Developers are confused because they expect to be able to show and hide the
error message just like they can show and hide any other content on the
page.

We tell them display: none or visiliby: hidden hides content from all users.

If they need to keep content available non-visually they have to hide it
visually by placing it off-screen or using the clip property.

They are also used to elements such as the label element not being
associated with input when hidden using display: none (verified with screen
readers).

 

I know the fix for this situation is not exactly rocket science: to
dynamically add an remove the aria-describedby connection in the validation
Javascript.

But the point is that this set up is not intuitive and if not done without
developer studying the attributes or without consulting with an
accessibility expert, they will get it wrong most of the time.

 

What if we can at least explicitly force the targets of these attributes to
be hidden using aria-hidden="true".

 

In this case the code would look like this:

<span id="error1" style="display: none;" aria-hidden="true">Error! First
name cannot exceed 30 characters, complain to your parents and find
something more suitable</span>

<input type="text" size="30" id="firstname" title="please enter your first
name" aria-describedby="error1">

 

We can simplify further by using a CSS selector to tie aria-hidden="true" to
display: none" (or create a custom class(.

This way accessibility of the error message comes packaged with the normal
Javascript and the developer does not have to explicitly add and remove the
attribute separately.

 

In my work in the trenches I sense a lot of confusion and some frustration
with how unintuitive the use of aria-describedby and aria-labelledby is, at
least for error messages and tooltips.

And I see the point actually.

The more intuitive an consistent we can make accessibility attributes with
what developers expect, the more accessible the content will be out of the
box.

So I hope that any discussion of either adding aria-errordescribedby
attribute or changing the expected behavior of aria-hidden could include
consideration of these real-world uses.

Ideally I would recommend that if developer hides content with
aria-hidden="true" that it is never included in the accessible name
calculation regardless of how it is referenced.

After all aria-hidden="true" sounds like it should hide the content, not
that it should hide the content in some circumstances but not in others.

This way we also do not have to get into discussions of repurposing the way
aria-describedby currently works.

 

Cheers

-Birkir

 

 
Received on Sunday, 12 October 2014 02:57:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:45:10 UTC