Re: HTML5 DL Element vs. WCAG 2.0 Success Criteria

In the words of Ramón, maybe two “anecdotical assertions” examples:

1)
in legislation documents I usually use:

<dl>
<dt>Article 1 - Scope</dt>
<dd>(…) here, the content of the article</dd>
<dt>Article 2 - …</dt>
(…)
</dl>

My assumption is, in a legislation document all the document is a list of definitions.

Yes. I also could express the semantic of the document with headings, like:

<h2>Article 1 - Scope</h2>
…
<h2>Article 2 - …</h2>
…

My last example use this one strategy: 
http://www.acessibilidade.gov.pt/pub/tratado_marraquexe_pt.html

Like a user, seems me that the semantic of the first construction is more robust (more meaning in my opinion).

But unfortunately the screen readers aren’t good with lists navigation. Either in <ul> lists type the UA (mainly assistive tech) could be more efficient. 

For example:

<ul>
<li>option 1
 <ul>
 <li>option 11</li>
 <li>option 12</li>
 </ul>
</li>
(…)
<li>option 2</li>
</ul>

If I want to navigate from “option 1” to “option 2” without passing through the 2 sub options of “option 1” I don’t have a way to do it. 

2) 

Sometimes I use:

<dl>
<dt>Main Menu</dt>
<dd>
<ul>
<li>option 1</li>
<li>option 2</li>
...
</ul></dd></dl>

instead of:
<h2>Main Menu</h2>
<ul>
<li>option 1</li>
<li>option 2</li>
…
</ul>

When I read WCAG 2.0, seems me that we need to spend the <hx> in the main content of the document and not in what is around it.

In our days, to resist to heading to this construction, I also use:

<ul title=“Main Menu”>
<li>option 1</li>
<li>option 2</li>
…
</ul>

—Jorge Fernandes

⠨⠚⠕⠗⠛⠑ ⠨⠋⠑⠗⠝⠁⠝⠙⠑⠎
 universalaccess.blogspot.com


No dia 09/02/2014, às 11:50, Steve Faulkner <faulkner.steve@gmail.com> escreveu:

> 
> 
> --
> 
> Regards
> 
> SteveF
> HTML 5.1
> 
> 
> On 8 February 2014 19:09, Ramón Corominas <listas@ramoncorominas.com> wrote:
> Hi, Steve.
> 
> Maybe you only find "anecdotical assertions" because the usage of definition lists is more or less anecdotical, too; or maybe because they are generally used for simple things like name-value pairs, that do not cause severe barriers.
> 
> this may indeed be the case 
> 
> Anyway, I'm not saying that they are always problematic, what I'm saying is that they are not usable unless in these simple situations, and that for those things we could use other structures with better support. Users would probably not say that there is a problem in a page without headings (nor landmarks), or in a menu without list markup, but they will not be able to browse the page so efficiently.
> 
> I agree using the most appropriate supported element(s) for the job is the right thing to do. 
> 
> Similarly, if a definition list contains other lists, it won't be navigable in an efficient way, and the relationships between "term" and "definition" tend to get lost; and anyway the structure of multiple definitions per term is never conveyed to current screen readers, so I think they are simply not accessibility supported and do not meet CR #4, which I do consider a problem.
> 
> I agree that this may be problematic 
> 
> For example, using JAWS I can know that the Glossary of WCAG 2.0 contains 117 terms -NVDA and VoiceOver say "166 elements"-, but I cannot find any efficient way to browse the different terms or even distinguish one term from the next unambiguously.
> 
> These sound like browser/AT bugs. 
> 
> In any case, I admit there is no data that can backup that definition lists are a problem, but I guess that there is also no data that can backup the contrary. I guess that there is no data at all about real world accessibility/usability of definition lists.
> 
> This is something that should be studied
> 
> That said, since the semantics of the original "definition" list has changed to something more like a "description" list, it is possible that it would be a useful structure if screen readers had support.
> 
> Probably the first step would be to not announce the list as a "definition" list... Sure that Michael Cooper is a good editor, but I would not say that he is the *definition* of "Editor" <wink>
> 
>  agreed, what I don't agree with is accepting that because either browsers or AT fail to support a features semantics as standardized that we should accept it. We as advocates (and users) need to be active in getting browsers and AT to support the features of HTML in use, as they are in use and will continue to be used.
> 
> 
> This is the course I take, for example  https://rawgithub.com/stevefaulkner/HTML5accessibility/master/index.html lists some of the current support issues and support successes in browsers for new features in HTML and bugs filed to fix.
> 
> Regards,
> Ramón.
> 
> 
> Steve wrote:
> 
> So far I have only seen anecdotal assertions that definition lists are a problem for screen reader users, if they are problematic it would be useful to have some actual data to back this up.
> 
>     Would it be possible to know how many of this 10% of pages are using
>     definition lists *properly*?
> 
> 
> I am collecting URLs so that those who are interested can do take  a look.
> 
> --
> 
> Regards
> 
> SteveF
> HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>
> 
> -- 
> Ramón Corominas
> Accessibility specialist
> Technosite - Fundación ONCE
> E: rcorominas@technosite.es
> T: @ramoncorominas
> P: +34 91 121 0330
> W: http://technosite.es
>