Using aria-describedby to replicate fieldset and legend

Complex forms should use a fieldset and legend to group similar inputs. The legend is announced along with label text for each input. This is especially helpful when form inputs are repetitive, such as mailing, billing, and work address information.

This example fixes a form that included a form within a table. It uses the aria-describedby attribute to connect the individual form inputs with a header cell. It was inspired by DeQue’s recent article for using ARIA to replace fieldset/legend in a set of radio buttons: ARIA-Group: a viable alternative for Fieldset / Legend?.
Continue Reading Using aria-describedby to replicate fieldset and legend

Class Equals Screen Reader Info

I’ve been using a little CSS trickery to hide content and data from the average user. I hate to mention it too often as it can open pandora’s box. There was a recent thread on the Microformat’s discussion list about this very topic. The gist of many programmers is that data worth sharing is data worth displaying.

However, there are times when your UED provides a design that lacks visual hooks for your screen reader users. A good example may be the ever-popular search form. Most sites will have an input and a button that says “search”. The label for this input is nowhere to be found.

The average sighted user can figure out such a simple form but the screen reader needs a bit more help. Here’s a sound clip of a screen reader trying to use the search form on Yahoo! Kids (.mp3). This was further complicated by the missing alt attribute on the image-based submit button.

I’ve also had to work with table based forms that need some assistance. The table is marked up with appropriate table headers and scopes, but the individual inputs lack labels due to the UED.

The simple solution

There are many ways to hide content via CSS. You want to avoid visibility:hidden and display:none. These will also hide it from the screen reader. You could use text-indent:-1000 em. I prefer using position:absolute; top:0; left:-1000em;. This hides the label by pushing it off screen yet the screen reader is still able to use it.

Updated CSS (updated 4/24/2008)

Adding a top position to your hidden may cause the page to jump when the item is focused. Only use a negative left position and leave the top position out of the equation.


Let’s look at the complicated table with hidden inputs. The table is properly coded with summary and scope. However, the table would still be difficult for a screen reader without form labels.

Here’s a sample of the HTML code:

Here’s the CSS for the labels

.srinfo {position:absolute; top:0; left:-1000em;}

Extending the hidden screen reader concept

I’ve written earlier about how Yahoo! Tech used a hidden collection of links to replicate an inaccessible flash movie. In a nutshell: screen readers cannot see a flash movie that has wmode:transparent. To get around this, we duplicated the flash content and moved it off-screen for screen readers and search engines.

You could also use this technique for providing information specific to screen reader users, such as:

Please note, this page uses JavaScript to continually update stock information. Look for the link: "disable stock updates" to turn this feature off

Hold the Presses, this isn’t perfect!

You can’t just throw anything off screen for the screen readers. The earlier Yahoo Tech example took about made 6 links invisible yet they were still accessible to keyboard users. So, remember, when you use the srinfo class to hide content for screen readers, keep in mind the impact on keyboard users.