RE: <details> longer description of <label> screenreader?

> From: Angie Radtke [mailto:a.radtke@derauftritt.de]
> Sent: 10 December 2015 07:14
> do you think it makes sence to use <details> for a longer description of a
> <label> inside a form?
> 
>   <input type="checkbox" id="JuHu" name="dog" value="1">
>    <label for="JuHu" id="desc">Dog</label>
> 
> <details  aria-labelledby="desc">
> <summary>Properties of a dog</summary>
> <p>Dogs are animals with a lot of fur, four legs and a tail </p> </details>
> 
Hello Angie.

This keeps the form neat because the extra information is hidden away. Unfortunately it doesn't work with screen readers because there is no programmatic association between the <input> and the extra information (so screen readers do not automatically announce the extra information when focus is on the checkbox ). When you tab onto the checkbox, only "Dogs" is announced. 

In the code aria-labelledby is used on the <details> element, with the idref of the <label> element as its value. This makes "Dogs" the accessible name for the <details> element, so when you tab onto the details/summary widget a screen reader will announce "Dogs" instead of "Properties of a dog". It doesn't create an association the other way though.

To create an association between the extra information and the <input>, you can use the aria-describedby attribute [1]. This provides an accessible description for the <input> that complements the accessible name provided by the <label> element.

<input aria-describedby="desc" type="checkbox" id="JuHu" name="dog" value="1">
<label for="JuHu">Dog</label>

<details>
<summary>Properties of a dog</summary>
<p id="desc">Dogs are animals with a lot of fur, four legs and a tail </p>
</details>

Now when you tab onto the checkbox, the screen reader will announce "Dogs" immediately followed by " Dogs are animals with a lot of fur, four legs and a tail".

It's also worth mentioning that accessibility support in browsers for the <details> and <summary> elements is not consistent [2]. You can do something about this for keyboard users and screen reader users though.

<summary role="group">
<details role="button" tabindex="0" aria-expanded="false">Properties of a dog</details>
<p> Dogs are animals with a lot of fur, four legs and a tail</p>
</details>

The group role indicates that the <summary> element is a group container, and the button role tells screen readers to treat the <details> element as a button (so people know it can be interacted with). 

The tabindex attribute ensures that keyboard users (sighted or otherwise) can tab onto the details/summary widget so they can operate it.

The aria-expanded attribute tells screen reader users about the state of the details/summary widget. When the widget is collapsed it should be set to "false", and when the widget is open it should be set to "true".

Léonie.
[1] http://www.w3.org/TR/wai-aria/states_and_properties#aria-describedby
[2] http://html5accessibility.com/


-- 
@LeonieWatson tink.uk Carpe diem

Received on Thursday, 10 December 2015 10:25:56 UTC