-
-
Notifications
You must be signed in to change notification settings - Fork 625
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Definition lists not exposed correctly #3858
Comments
Comment 1 by bgaraventa on 2014-02-10 19:08 |
Comment 2 by jmuheim on 2014-10-07 13:59 |
This does sound like a potential candidate for Project Webfix. Thoughts? @feerrenrut |
Firstly, I can still reproduce this by navigating to the definition list displayed in the description of this issue while using NVDA Version: The webfix project is not attempting to fix every issue that occurs when using the web. Rather, it is intended to try to fix a select group of particularly troublesome issues. I don't think this issue fits into that category. While the behaviour here could be improved, and some of the semantics of the definition list are lost, my guess is that definition lists are not frequently encountered by users and the lost semantics can generally be picked up based on the context of the definition list. |
Would love to see this addressed. I was contemplating switching our template over from using uls to dls but it's not going to happen if the screen reader support is lacking. It's a lot of overhead to expect people to mark things up with ARIA vs. just having it work as intended. |
This doesn't mean you can't use them, it just means the semantics aren't quite correct. I'd advise switching to a DL still, because other screen readers will benefit possibly, and your sighted audience will for sure. |
on complex websites where huge databases are displayed such as worldbank or EIU statistics there are such definitions lists. I can also see such lists often in corporate environment on sharepoint solutions. I don't know how hard this is to implement but I think having such a feature in document formating settings would help in boosting efficiency. |
Just want to remind folks that
The number of child elements of a And I fully agree that NVDA should not treat Side note: ARIA doesn't yet have role parity with all of these either. |
Is it just technical issues that block this ticket or are there any other reasons not to announce DLs properly? |
Is there a status update on this bug? It would be great if NVDA could implement description lists as JAWS and VoiceOver have. |
My team is also blocked on this right now. Are there any plans to address this in the near future so we can determine how to proceed? |
Currently no plans to look at this. I have however updated the issue description to make it more readable. This might make it a little easier for some or all of this to get looked at. |
I'm quite curious, which ARIA attribute did you use to fix this issue? Could you share an example? |
Just bumping this as there was a query about it from @mausmalone on Twitter overnight. |
Link to the draft for ARIA 1.3 which is due to introduce explicit roles to achieve parity with HTML's DL/DT/DD https://w3c.github.io/aria/#associationlist Note: There is some dissent about the lengthy nomenclature. |
Does anyone know if this issue was ever propperly fixed as I'm using NVDA and all it says is "list with N items" when entering the list and there is no indication of even the individual |
As far as I can see, a list entry can have both multiple DT and multiple DD elements. Incidentally, this not only occurs on the web, but also with many PDF documents. |
Sadly, ARIA themselves seem to have failed to get that memo, defining (per the link @brennanyoung posted) DIV children of DLFrom the HTML spec, an additional complication is that the children of <dl>
<div>
<dt> Last modified time </dt>
<dd> 2004-12-23T23:33Z </dd>
</div>
<div>
<dt> Recommended update interval </dt>
<dd> 60s </dd>
</div>
<div>
<dt> Authors </dt>
<dt> Editors </dt>
<dd> Robert Rothman </dd>
<dd> Daniel Jackson </dd>
</div>
</dl> As a child of Nested DLsWhile the HTML spec doesn't explicitly address nested
|
IMHO multiple DT or DD elements nested within a DIV or not could be treated as an LI within a virtual UL.
becomes
Now the DL is a key-value pair. I see that there is a semantic point for having multiple DT elements, but I guess that it could be sufficient to slump them all together into a single virtual DT without the virtual nested list I described above. |
I largely agree, but the sake of information fidelity it might make more sense to view them as items of an ordered list. As the HTML spec cautions, "The order of the list of groups, and of the names and values within each group, may be significant." They also present this example:
The intent, it seems, is to support a |
@ferdnyc I shortly thought about proposing an OL, but didn't think the ordering important. But you (and the authors of the spec) are right, the order could be important. |
May I suggest to split this problem into two issues:
In this way we can cover most (anecdotally) issues and had the multilevel implementation open until more is known. Just tested an example with:
And it's announced as "list with 4 items" not communicating the term > definition semantics at all (as I would expect it to do). Sometimes term definition hierarchy is probably logical to users, but sometimes it is crucial for the understanding and lack of it may be a huge problem... |
Agreed, the ideal situation (in my view) would have it announced as a "description list with two entries" or "...two items". Ditto this one, with the structure of the first entry being read out only when it's visited. <dl>
<dt>Students</dt>
<dd>Judy</dd>
<dd>Robin</dd>
<dt>Teacher</dt>
<dd>Melissa</dd>
</dl> Whether this should be announced as having two or three entries/items, I don't know: <dl>
<dt>Student</dt>
<dd>Judy</dd>
<dt>Staff</dt>
<dt>Teacher</dt>
<dd>Melissa</dd>
</dl> ...though I do feel it's a question worth answering definitively, in order to implement correct behavior. |
I'd love to see @nvaccess address this. Other screen readers handle it (it's been a while since I last tested this). For a dl with two dt and one dd for the first dt, two dd for the second, I'd expect to hear there is a list with two terms, then when I get to the first dt I'd expect to hear it associated with one item; for the second term, a list with two items. Should I work with the W3C HTML or AGWG to clarify expected behavior, or is this left for AT to decide, or browsers? |
Steps to reproduce:
I'm not really sure about the correctness or utility of nested DL's. This isn't specifically mentioned in the html spec
or on MDN - DL element but I have included in the example any way since many comments seem to mention it.
Example case
See below or codepen:
Test case
Actual behavior:
Reading in browse mode gives the following text:
The I key then only navigates through the DT elements, which is more confusing.
Expected behavior:
Criticisms / expectations collected from comments from this issue and other closed duplicates. Bear in mind this is up for discussion.
dl
s are read as lists (i.e. "list"), announce instead "Description List" (prior suggestions were "definition list", however see MDN)dt
elements.dt
element.dt
todt
element.dt
has more than onedd
elements associated with it, announce "Term with definitions"dl
s is not announced, parent/child relationships should be expressed.dt
anddd
elements as the number of items in the list which is misleading.Name and version of other software in use when reproducing the issue:
Chrome / Edge / Firefox
The text was updated successfully, but these errors were encountered: