E-mail List Archives

Search E-mail List Archives for

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

From: Dennis Deacon
Date: Sat, Aug 15 2015 9:59AM
Subject: Definition Lists and Accessibility
No previous message | Next message →

I've been a fan of definition lists for a while now. I use them when have
have a list of paired information, such as a FAQ. To me, this makes
semantic sense.

During the past few months however, I have receive a sizable amount of
feedback stating that definition lists can confuse screen reader users and
should be avoided, with the exception of possibly a glossary of terms.
While my intent is to do what is accessible, I can't get past the semantics
of a definition list making sense in other cases. Admittedly, I used it
more for layout of information, but I've drifted away from that.

Can someone point out specific information on how definition lists can
confuse screen reader users, and the best alternative for paired lists?

--
Dennis Deacon
Email: = EMAIL ADDRESS REMOVED =
Website/Portfolio: dennisdeacon.com
Blog: dennisdeacon.com/blog
LinkedIn Profile: linkedin.com/in/dennisdeacon

From: Léonie Watson
Date: Sat, Aug 15 2015 11:13AM
Subject: Re: Definition Lists and Accessibility
← Previous message | Next message →

> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ]
> On Behalf Of Dennis Deacon
> Sent: 15 August 2015 17:00
> Can someone point out specific information on how definition lists can
> confuse screen reader users, and the best alternative for paired lists?
>

Some screen readers do not differentiate definition lists from other types of list. Take the following example:

<dl>
<dt>Blanco</dt>
<dd>Blanco tequila is...</dd>
<dt>Reposado</dt>
<dd>Tequila reposado is...</dd>
</dl>

Jaws in Firefox reports it as "Definition list with 2 items", but NVDA in Firefox reports it as "List with 4 items". To an NVDA user, the list is therefore indistinguishable from a <ul> with four <li> children.

It's worth noting that a definition list is the correct way to mark up a list of paired items. Changing markup patterns to satisfy the vagaries of specific assistive technologies tends to be a slippery slope.

Léonie.

--
Senior accessibility engineer @PacielloGroup @LeonieWatson

From: Dennis Deacon
Date: Sat, Aug 15 2015 1:48PM
Subject: Re: Definition Lists and Accessibility
← Previous message | Next message →

Thanks for the information on how screen readers handle definition lists.
And I agree about the slippery slope; reminds me when the web standards
movement first started.

One more question: would there be a way to use definition lists for
semantic purposes, while temporarily hacking them so screen readers don't
become confused?

Dennis Deacon



On Sat, Aug 15, 2015 at 10:59 AM, Dennis Deacon < = EMAIL ADDRESS REMOVED = >
wrote:

> I've been a fan of definition lists for a while now. I use them when have
> have a list of paired information, such as a FAQ. To me, this makes
> semantic sense.
>
> During the past few months however, I have receive a sizable amount of
> feedback stating that definition lists can confuse screen reader users and
> should be avoided, with the exception of possibly a glossary of terms.
> While my intent is to do what is accessible, I can't get past the semantics
> of a definition list making sense in other cases. Admittedly, I used it
> more for layout of information, but I've drifted away from that.
>
> Can someone point out specific information on how definition lists can
> confuse screen reader users, and the best alternative for paired lists?
>
> --
> Dennis Deacon
> Email: = EMAIL ADDRESS REMOVED =
> Website/Portfolio: dennisdeacon.com
> Blog: dennisdeacon.com/blog
> LinkedIn Profile: linkedin.com/in/dennisdeacon
>



--
Dennis Deacon
Email: = EMAIL ADDRESS REMOVED =
Website/Portfolio: dennisdeacon.com
Blog: dennisdeacon.com/blog
LinkedIn Profile: linkedin.com/in/dennisdeacon

From: Léonie Watson
Date: Sun, Aug 16 2015 2:57AM
Subject: Re: Definition Lists and Accessibility
← Previous message | Next message →

> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ]
> On Behalf Of Dennis Deacon
> Sent: 15 August 2015 20:48
>
> One more question: would there be a way to use definition lists for semantic
> purposes, while temporarily hacking them so screen readers don't become
> confused?

Not that I can think of - at least not without disturbing those screen readers that do support definition lists properly, or reducing UX for others in different ways.

One option might be to use a <ul> with something like "term = definition" as the content of each <li>. It would be announced as a standard list by screen readers, but that would mean that people using screen readers that do support definition lists would lose that information. The equals sign would provide a visual indication of the relationship between the term and the definition, but there's a chance some screen readers wouldn't announce the equals sign because of variable punctuation settings.

Which leads me back to thinking that using the right markup for the job is probably the best bet in the scheme of things.

Léonie.

--
Senior accessibility engineer @PacielloGroup @LeonieWatson

From: _mallory
Date: Sun, Aug 16 2015 7:01AM
Subject: Re: Definition Lists and Accessibility
← Previous message | Next message →

Sometimes, if it makes sense with the DL already, developers put
<h*> headings inside the DTs. This should still look "wrong" to
any AT that sees a DL as a UL, but you'll have a (list item with) a
heading-level-whatever, then another list item, then a (list item
with) a heading-level-whatever etc.


On Sun, Aug 16, 2015 at 09:57:21AM +0100, Léonie Watson wrote:
> Not that I can think of - at least not without disturbing those screen readers that do support definition lists properly, or reducing UX for others in different ways.
>
> One option might be to use a <ul> with something like "term = definition" as the content of each <li>. It would be announced as a standard list by screen readers, but that would mean that people using screen readers that do support definition lists would lose that information. The equals sign would provide a visual indication of the relationship between the term and the definition, but there's a chance some screen readers wouldn't announce the equals sign because of variable punctuation settings.
>
> Which leads me back to thinking that using the right markup for the job is probably the best bet in the scheme of things.
>
> Léonie.

From: Guy Hickling
Date: Sun, Aug 16 2015 4:31PM
Subject: Re: Definition Lists and Accessibility
← Previous message | Next message →

Don't mess up your HTML markup (and risk causing problems for users of
those products that do it correctly) to try to cater for the shortcomings
of a particular screen reader or AT, because while you are doing that the
manufacturer is probably updating their product to do the correct thing
anyway! - and if they don't, and they allow their product to to fall too
far behind other similar products, people will soon stop using them and the
problem will have been solved for you.
Regards,
Guy

From: Lynn Holdsworth
Date: Thu, Aug 20 2015 8:14AM
Subject: Re: Definition Lists and Accessibility
← Previous message | Next message →

Hi all,

Yesterday we tested a complex definition list with 3 screenreaders.

The list contained 6 terms, each with a whole bunch of definitions,
making 347 items in all.

The screenreadders:
* JAWS correctly identified the list as a definition list with 6
items. But arrowing down the items in the list, it didn't flag up
which items were terms and which were definitions, so the paradigm
became very confusing.

* WindowEyes described it as a list with 347 items, but when arrowing
through the list, it identified each item as a DT or DD, wich was very
helpful.

* NVDA, like WindowEyes,picks up a list with 347 items, and like Jaws
doesn't differentiate between terms and definitions, offering a worst
of both worlds scenario.

* VoiceOver: we only did a quick test with VoiceOver on a Mac, but it
seemed to behave in a way similar to NVDA.

I sympathise with the school of thought that says we should always use
semantic mark-up and not come up with hacky work-arounds for
screenreaders; but in this scenario, where the lack of support in all
screenreaders is likely to cause serious confusion, I would report the
bug and opt for a work-around. I'm advising the client to use either
nested lists or headings for terms followed by lists of definitions.

Best, Lynn

On 16/08/2015, Guy Hickling < = EMAIL ADDRESS REMOVED = > wrote:
> Don't mess up your HTML markup (and risk causing problems for users of
> those products that do it correctly) to try to cater for the shortcomings
> of a particular screen reader or AT, because while you are doing that the
> manufacturer is probably updating their product to do the correct thing
> anyway! - and if they don't, and they allow their product to to fall too
> far behind other similar products, people will soon stop using them and the
> problem will have been solved for you.
> Regards,
> Guy
> > > > >

From: Moore,Michael (HHSC)
Date: Thu, Aug 20 2015 8:37AM
Subject: Re: Definition Lists and Accessibility
← Previous message | Next message →

Was the person doing the testing an experienced screen reader user with a visual impairment or person with normal vision who uses a screen reader for testing?

I ask this because we often make a lot of assumptions about understandability without doing actual user testing. The result is that we overthink some things and make bad assumptions about others.

People who use screen readers or other assistive technologies daily, for access to information and services, not to "test for accessibility" have a much different experience than we sighted accessibility testers and our assumptions about what causes confusion and what does not is often wrong.

What is the purpose of the list? How will the list be used? Is the information well organized? Does the user know from context that this is a list of terms with multiple definitions for each term? Think of how a print dictionary is organized. The terms are in alphabetical order and each definition is prefaced by a number making it fairly obvious which is which. If there are a lot of terms is there a mechanism that separates them into logical groups making it easier to find the one that you want? This is like the tabs on the side of your print dictionary.

There is no hard and fast rule that says all glossary's or FAQ's or similar lists must be organized using a definition list, or that it must be a single list. Experiment with multiple options and test with real users including people with disabilities. I'll bet that you are surprised by the results. At the very least chances are that your end product is more usable for everyone. </rant>

Mike Moore
Accessibility Coordinator
Texas Health and Human Services Commission
Civil Rights Office
(512) 438-3431 (Office)
(512) 574-0091 (Cell)

-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Lynn Holdsworth
Sent: Thursday, August 20, 2015 9:14 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Definition Lists and Accessibility

Hi all,

Yesterday we tested a complex definition list with 3 screenreaders.

The list contained 6 terms, each with a whole bunch of definitions, making 347 items in all.

The screenreadders:
* JAWS correctly identified the list as a definition list with 6 items. But arrowing down the items in the list, it didn't flag up which items were terms and which were definitions, so the paradigm became very confusing.

* WindowEyes described it as a list with 347 items, but when arrowing through the list, it identified each item as a DT or DD, wich was very helpful.

* NVDA, like WindowEyes,picks up a list with 347 items, and like Jaws doesn't differentiate between terms and definitions, offering a worst of both worlds scenario.

* VoiceOver: we only did a quick test with VoiceOver on a Mac, but it seemed to behave in a way similar to NVDA.

I sympathise with the school of thought that says we should always use semantic mark-up and not come up with hacky work-arounds for screenreaders; but in this scenario, where the lack of support in all screenreaders is likely to cause serious confusion, I would report the bug and opt for a work-around. I'm advising the client to use either nested lists or headings for terms followed by lists of definitions.

Best, Lynn

On 16/08/2015, Guy Hickling < = EMAIL ADDRESS REMOVED = > wrote:
> Don't mess up your HTML markup (and risk causing problems for users of
> those products that do it correctly) to try to cater for the
> shortcomings of a particular screen reader or AT, because while you
> are doing that the manufacturer is probably updating their product to
> do the correct thing anyway! - and if they don't, and they allow their
> product to to fall too far behind other similar products, people will
> soon stop using them and the problem will have been solved for you.
> Regards,
> Guy
> > > archives at http://webaim.org/discussion/archives
> >

From: _mallory
Date: Thu, Aug 20 2015 11:23AM
Subject: Re: Definition Lists and Accessibility
← Previous message | Next message →

Regular user or novice, I would expect any AT to do the following at
minimum:

1. correctly state the number of items by recognising that it's a
DL (so not doubling the number of items)
2. offer some manner for users to know where the DT ends and the DD
begins. Whether it's done like two separate paragraphs or something
more crazy, I don't care: markup wise, it's perfectly allowed and
legal to, for example, leave no spaces between tags.

<hx>Foods</hx><dl><dt>Cheese</dt><dd>stuff about cheese, which may
not even be a "proper" sentence; like car manuals</dd><dt>Etc...</dt>
...</dl>

Any AT that cannot do at least as much as a browser in knowing the
difference between "Cheese" and "stuff about cheese..." isn't doing
the users any good.

Now I'm not saying NVDA and VO don't, cause I dunno, but *if* it's
true that there's no sane way for a user to differentiate the
terms from the defs then I would consider using another markup
setup. And I say this loving DLs with all my heart.

So, has anyone done any recent user testing (novice..experienced
SR users) with DLs? Recent indeed. I'd love to know.

_mallory

On Thu, Aug 20, 2015 at 02:37:46PM +0000, Moore,Michael (HHSC) wrote:
> Was the person doing the testing an experienced screen reader user with a visual impairment or person with normal vision who uses a screen reader for testing?
>
> I ask this because we often make a lot of assumptions about understandability without doing actual user testing. The result is that we overthink some things and make bad assumptions about others.
>
> People who use screen readers or other assistive technologies daily, for access to information and services, not to "test for accessibility" have a much different experience than we sighted accessibility testers and our assumptions about what causes confusion and what does not is often wrong.
>
> What is the purpose of the list? How will the list be used? Is the information well organized? Does the user know from context that this is a list of terms with multiple definitions for each term? Think of how a print dictionary is organized. The terms are in alphabetical order and each definition is prefaced by a number making it fairly obvious which is which. If there are a lot of terms is there a mechanism that separates them into logical groups making it easier to find the one that you want? This is like the tabs on the side of your print dictionary.
>
> There is no hard and fast rule that says all glossary's or FAQ's or similar lists must be organized using a definition list, or that it must be a single list. Experiment with multiple options and test with real users including people with disabilities. I'll bet that you are surprised by the results. At the very least chances are that your end product is more usable for everyone. </rant>
>
> Mike Moore
> Accessibility Coordinator
> Texas Health and Human Services Commission
> Civil Rights Office
> (512) 438-3431 (Office)
> (512) 574-0091 (Cell)

From: Olaf Drümmer
Date: Thu, Aug 20 2015 2:07PM
Subject: Re: Definition Lists and Accessibility
← Previous message | Next message →

I think this shows that definition lists were just ill conceived at the times when that concept was introduced.

If it had for example been called "key value pair list" everybody would have understood what it might be used for, without reading a single piece of specification. And we could use it for ingredient lists in cooking recipes, restaurant menus, price lists, … and of course definition lists.

I will embarrass myself here by admitting that I only learnt about definition lists a few years back when entering the field of accessible content. Before that, in tens of years of reading and writing lots of structured and not-so-well-structured content it never occurred to me that a concept like definition list is actually needed - other mechanisms would work sufficiently well, like nested lists or two column tables. And I guess there is a reason why (almost all?) authoring tools do not have a "definition list" formatting option. I can nonetheless see value in having a concept like "list of key value pairs" but still do believe it is not an indispensable concept when it comes to establishing a core set of tags for a language like HTML, rather it feels like an example of document-structure-over-engineering to me. I believe one can live a happy, document-rich life without ever thinking about definition lists…


Olaf



On 20 Aug 2015, at 19:23, _mallory < = EMAIL ADDRESS REMOVED = > wrote:

> Regular user or novice, I would expect any AT to do the following at
> minimum:
>
> 1. correctly state the number of items by recognising that it's a
> DL (so not doubling the number of items)
> 2. offer some manner for users to know where the DT ends and the DD
> begins. Whether it's done like two separate paragraphs or something
> more crazy, I don't care: markup wise, it's perfectly allowed and
> legal to, for example, leave no spaces between tags.
>
> <hx>Foods</hx><dl><dt>Cheese</dt><dd>stuff about cheese, which may
> not even be a "proper" sentence; like car manuals</dd><dt>Etc...</dt>
> ...</dl>
>
> Any AT that cannot do at least as much as a browser in knowing the
> difference between "Cheese" and "stuff about cheese..." isn't doing
> the users any good.
>
> Now I'm not saying NVDA and VO don't, cause I dunno, but *if* it's
> true that there's no sane way for a user to differentiate the
> terms from the defs then I would consider using another markup
> setup. And I say this loving DLs with all my heart.
>
> So, has anyone done any recent user testing (novice..experienced
> SR users) with DLs? Recent indeed. I'd love to know.
>
> _mallory
>
> On Thu, Aug 20, 2015 at 02:37:46PM +0000, Moore,Michael (HHSC) wrote:
>> Was the person doing the testing an experienced screen reader user with a visual impairment or person with normal vision who uses a screen reader for testing?
>>
>> I ask this because we often make a lot of assumptions about understandability without doing actual user testing. The result is that we overthink some things and make bad assumptions about others.
>>
>> People who use screen readers or other assistive technologies daily, for access to information and services, not to "test for accessibility" have a much different experience than we sighted accessibility testers and our assumptions about what causes confusion and what does not is often wrong.
>>
>> What is the purpose of the list? How will the list be used? Is the information well organized? Does the user know from context that this is a list of terms with multiple definitions for each term? Think of how a print dictionary is organized. The terms are in alphabetical order and each definition is prefaced by a number making it fairly obvious which is which. If there are a lot of terms is there a mechanism that separates them into logical groups making it easier to find the one that you want? This is like the tabs on the side of your print dictionary.
>>
>> There is no hard and fast rule that says all glossary's or FAQ's or similar lists must be organized using a definition list, or that it must be a single list. Experiment with multiple options and test with real users including people with disabilities. I'll bet that you are surprised by the results. At the very least chances are that your end product is more usable for everyone. </rant>
>>
>> Mike Moore
>> Accessibility Coordinator
>> Texas Health and Human Services Commission
>> Civil Rights Office
>> (512) 438-3431 (Office)
>> (512) 574-0091 (Cell)
> > > >

From: Dennis Deacon
Date: Thu, Aug 20 2015 3:49PM
Subject: Re: Definition Lists and Accessibility
← Previous message | Next message →

Thanks again for this valuable discussion.

Dennis Deacon

On Sat, Aug 15, 2015 at 2:48 PM, Dennis Deacon < = EMAIL ADDRESS REMOVED = > wrote:

> Thanks for the information on how screen readers handle definition lists.
> And I agree about the slippery slope; reminds me when the web standards
> movement first started.
>
> One more question: would there be a way to use definition lists for
> semantic purposes, while temporarily hacking them so screen readers don't
> become confused?
>
> Dennis Deacon
>
>
>
> On Sat, Aug 15, 2015 at 10:59 AM, Dennis Deacon < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> I've been a fan of definition lists for a while now. I use them when have
>> have a list of paired information, such as a FAQ. To me, this makes
>> semantic sense.
>>
>> During the past few months however, I have receive a sizable amount of
>> feedback stating that definition lists can confuse screen reader users and
>> should be avoided, with the exception of possibly a glossary of terms.
>> While my intent is to do what is accessible, I can't get past the semantics
>> of a definition list making sense in other cases. Admittedly, I used it
>> more for layout of information, but I've drifted away from that.
>>
>> Can someone point out specific information on how definition lists can
>> confuse screen reader users, and the best alternative for paired lists?
>>
>> --
>> Dennis Deacon
>> Email: = EMAIL ADDRESS REMOVED =
>> Website/Portfolio: dennisdeacon.com
>> Blog: dennisdeacon.com/blog
>> LinkedIn Profile: linkedin.com/in/dennisdeacon
>>
>
>
>
> --
> Dennis Deacon
> Email: = EMAIL ADDRESS REMOVED =
> Website/Portfolio: dennisdeacon.com
> Blog: dennisdeacon.com/blog
> LinkedIn Profile: linkedin.com/in/dennisdeacon
>



--
Dennis Deacon
Email: = EMAIL ADDRESS REMOVED =
Website/Portfolio: dennisdeacon.com
Blog: dennisdeacon.com/blog
LinkedIn Profile: linkedin.com/in/dennisdeacon

From: Lucy Greco
Date: Fri, Aug 21 2015 10:13AM
Subject: Re: Definition Lists and Accessibility
← Previous message | No next message

hello:
you said' arrowing down the items' well here may be the problem. if you
are using the screen reader properly you should not arrow thru a list,
definition or not. you should use the item by item navigation.
once your in the list use i to move thru it and see if that makes a
difference.
as an " "expert" screen reader user i did not know this my self for
several years. this is why if you are wanting to test properly with a
screen reader its best to get reel users and more then one smile. Lucy

On Thu, Aug 20, 2015 at 2:49 PM, Dennis Deacon < = EMAIL ADDRESS REMOVED = > wrote:

> Thanks again for this valuable discussion.
>
> Dennis Deacon
>
> On Sat, Aug 15, 2015 at 2:48 PM, Dennis Deacon < = EMAIL ADDRESS REMOVED = >
> wrote:
>
> > Thanks for the information on how screen readers handle definition lists.
> > And I agree about the slippery slope; reminds me when the web standards
> > movement first started.
> >
> > One more question: would there be a way to use definition lists for
> > semantic purposes, while temporarily hacking them so screen readers don't
> > become confused?
> >
> > Dennis Deacon
> >
> >
> >
> > On Sat, Aug 15, 2015 at 10:59 AM, Dennis Deacon < = EMAIL ADDRESS REMOVED = >
> > wrote:
> >
> >> I've been a fan of definition lists for a while now. I use them when
> have
> >> have a list of paired information, such as a FAQ. To me, this makes
> >> semantic sense.
> >>
> >> During the past few months however, I have receive a sizable amount of
> >> feedback stating that definition lists can confuse screen reader users
> and
> >> should be avoided, with the exception of possibly a glossary of terms.
> >> While my intent is to do what is accessible, I can't get past the
> semantics
> >> of a definition list making sense in other cases. Admittedly, I used it
> >> more for layout of information, but I've drifted away from that.
> >>
> >> Can someone point out specific information on how definition lists can
> >> confuse screen reader users, and the best alternative for paired lists?
> >>
> >> --
> >> Dennis Deacon
> >> Email: = EMAIL ADDRESS REMOVED =
> >> Website/Portfolio: dennisdeacon.com
> >> Blog: dennisdeacon.com/blog
> >> LinkedIn Profile: linkedin.com/in/dennisdeacon
> >>
> >
> >
> >
> > --
> > Dennis Deacon
> > Email: = EMAIL ADDRESS REMOVED =
> > Website/Portfolio: dennisdeacon.com
> > Blog: dennisdeacon.com/blog
> > LinkedIn Profile: linkedin.com/in/dennisdeacon
> >
>
>
>
> --
> Dennis Deacon
> Email: = EMAIL ADDRESS REMOVED =
> Website/Portfolio: dennisdeacon.com
> Blog: dennisdeacon.com/blog
> LinkedIn Profile: linkedin.com/in/dennisdeacon
> > > > >



--
Lucia Greco
Web Accessibility Evangelist
IST - Architecture, Platforms, and Integration
University of California, Berkeley
(510) 289-6008 skype: lucia1-greco
http://webaccess.berkeley.edu
Follow me on twitter @accessaces