W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2014

Re: HTML5 DL Element vs. WCAG 2.0 Success Criteria

From: Steve Faulkner <faulkner.steve@gmail.com>
Date: Sun, 9 Feb 2014 11:50:31 +0000
Message-ID: <CA+ri+Vm=Y91zVxuOnrkwMakJSnwxw_2k2G4i5sQQJyvsUYkzdQ@mail.gmail.com>
To: Ramón Corominas <listas@ramoncorominas.com>
Cc: WAI Interest Group <w3c-wai-ig@w3.org>
--

Regards

SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>


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.htmllists
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
>
Received on Sunday, 9 February 2014 11:51:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:50 UTC