VoiceOver on iOS 14 Supports Description Lists
The <dl>
has existed since HTML+, or 1993, when it was called definition list. VoiceOver on iOS has existed since 2009, when it was introduced with the iPhone 3GS.
Neither VoiceOver on iOS nor iPadOS had support for this core feature of HTML that was in existence for 16 years when VoiceOver was released — until now with the release of iOS / iPadOS version 14.
Frustrated at Apple’s failure to accessibly implement such a basic feature of HTML, a few months ago I made a test to see if I could use some combination of CSS and/or ARIA (1.1 and the draft 1.2) to get VoiceOver to recognize a <dl>
as anything other than one long block of run-on text. I have embedded that test as well:
See the Pen Description Lists for VO/iOS by Adrian Roselli (@aardrian) on CodePen.
That pen explains each technique I tried, along with the support for each in iOS 12 through 14. It has historically not been good. But with no fanfare from Apple that has changed.
Standard <dl>
, Swiped
The following code:
<dl>
<dt>farrago</dt>
<dd>a confused mixture; hodgepodge</dd>
<dt>louche</dt>
<dd>not reputable or decent</dd>
<dt>parse</dt>
<dd>to examine in a minute way; analyze critically</dd>
<dt>argot</dt>
<dd>the language used by a particular type or group of people; an often more or less secret vocabulary and idiom peculiar to a particular group</dd>
</dl>
Yields the following results as I swipe through the content:
This is good. VoiceOver reads the the text of the first <dt>
, then “definition list start”, then “term”. As it moves through the list it reads the text of each <dt>
followed by “term” and the text of each <dd>
followed by “definition”. For the last item it reads the text of the <dd>
, followed by “definition list end”, and then “definition”.
A bit wordy, but probably less confusing than if it announced each as “key” and “value”.
Quirks
Be aware that while VoiceOver support exists, it is not perfect.
Standard <dl>
, Read-all
With the exact same code, if I start at the heading preceding it and choose to read from that point forward, the output is much different.
This is not good. VoiceOver reads it as plain text, with no pauses between nodes, no announcement of elements, and no announcement of entering nor exiting the list.
Essentially the same as all previous versions of VoiverOver in iOS.
Standard <dl>
, Using List Styles
Here I use the same HTML:
<dl class="dl-with-bullets">
<dt>gamut</dt>
<dd>an entire range or series</dd>
<dt>assail</dt>
<dd>to attack violently; assault</dd>
<dt>empirical</dt>
<dd>originating in or based on observation or experience</dd>
<dt>longueur</dt>
<dd>a dull and tedious passage or section (as of a book, play, or musical composition) — usually used in plural</dd>
</dl>
I also give the items list styles:
dl.dl-with-bullets {
list-style-type: disc;
padding: 0;
margin-left: 0;
}
dl.dl-with-bullets > * {
display: list-item;
margin: 0;
padding: 0;
margin-left: 2em;
}
This yields the following results as I swipe through the content:
This is not good. VoiceOver reads the first bullet on the <dt>
, then “definition list start”. It does not indicate there is a <dt>
nor <dd>
for each item, but does repeat the bullet announcement throughout the list (as a virtual cursor stop, requiring each list item to take two swipes to get through). For the last <dd>
, VoiceOver reads the bullet, then the text, then “definition list end”.
Takeaway
Understand how your users might access content in your description lists. If they tend to have the entire page read to them, the utility might be low. If they have a more methodical approach (owing to the nature of the content, density of information, existing patterns, and so on), then description lists could be handy.
Be aware that VoiceOver persists in its list style quirks. CSS display property bugs in Safari can override your description list semantics. Other list properties are likely to do it as well, so test.
Finally, while these may be called description lists, and the ARIA 1.2 (draft) refers to them as association lists, VoiceOver will announces them as definition lists. This is mostly only important when it comes to end user support.
Update: 22 December 2022
I have more current results, across more browsers, in my mis-named post Brief Note on Description List Support.
4 Comments
Would it be an unreasonable takeaway that VoiceOver on iOS just plain sucks?
Anyway, would just tacking on a colon after each term be OK, or no beuno?
The context would be a section with personal details, like “name”, “gender”, “pronouns”, etc, etc
and so forth and suchIDK even really why I’m posting this here I guess I’m just being a real #lazyweb
In response to .For screen readers that support description lists (by announcing counts, by allowing list and list item navigation), just adding a colon robs these users of the ability to navigate and use the content as they want. Which we are only discussing because VoiceOver on iOS has been so problematic for so long.
Hello,
I just tested this morning in iOS 16 latest release in read all and now it is read properly as a list, not as a plein text.
Maybe you can update this article.
Have a nice day.
In response to .I guess I should have linked to Brief Note on Description List Support, posted a couple weeks ago.
Leave a Comment or Response