[Bug 13668] Generated content must be accessible

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13668

theimp@iinet.net.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |theimp@iinet.net.au

--- Comment #7 from theimp@iinet.net.au 2011-11-29 14:59:50 UTC ---
> However, authors continue to abuse generated content.

This is, fundamentally, the problem.

> I think this accessibility failure reflects a design error in HTML4 of treating the numbering of lists as a stylistic rather than content attribute:

This seems more an error of authors (which HTML5 seems to want to make very
easy with the reintroduction of @value and related presentational attributes).
Numbering is not implied by Ordered Lists.

As you say:

> When the numbering used in a list is significant, authors should arguably use <p> or <div> elements with numbers in the DOM text.

Indeed.

> User agents should arguably copy <ol> elements with numbering of some sort, since the fact that they are ordered lists is part of the content.

Exactly.

OL implies order (structure), not numbering generally (presentation) or
specific numbers (content). All that is required of the user agent is that (by
some method) the order is conveyed. In the case of numbering, this only implies
that earlier entries have lower numbers than later entries, and not that any
particular number is applied. If a particular number is required by the author,
that number must be specified as content.

On the other hand, user agents are *not* copying numbering. And authors are
*not* separating content from presentation.

> For example, given a DOM element reference "el" you can query the content of ::before using:

The ::marker pseudoelement from the CSS Lists And Counters Module Level 3
remains largely unimplemented in current browsers, meaning that, in the case of
lists, ECMAscript cannot determine the value, or set it (in this way).

Furthermore, this makes it very cumbersome for authors using non-User Agent
(generic ECMAscript) solutions, because the "generated content" that they're
looking for in the case of a list item, for example, might be in the ::before
pseudoelement, or in the ::marker pseudoelement, or in the value attribute, or
in none of them, or with different values in each (possibly with browsers
choosing which one is ultimately rendered, differently from each other).

So already, authors who do not know/care about accessibility have at least
three different ways of inserting vital content as non-content, and no reliable
way for users or Assistive Technologies to access that content.

Even before it reached this level of complexity, the typical response of voice
Assistive Technologies was to number ordered lists themselves (that is, count
up from one, in exactly list order), and always simply use the text "bullet"
for unordered lists. While this has started to change in some cases, it has
also become generally worse than it used to be.

Perhaps something does need to happen at this (or another) level.

One possibility might be to standardize, as part of HTML, a method of
generating an intermediate format for export (whether to be saved to disk, or
presented to Assistive Technologies, or copied to the clipboard, or converted
to a non-HTML file format, etc.). In such a format, the HTML, CSS, scripts, and
other resources could be interspersed in a standard way, with a view to
preserving content rather than reproducing the original. For example, all
required CSS rules would be reduced to only those which apply (last of each
type) to a given element, and stored in the style attribute of each element.
content: style rules could be expanded into actual content characters in a new
element in the appropriate position. And so on.

This would be a fallback method, because unlike the DOM it would likely be too
difficult to change in real-time; but it would allow standardized access to
Assistive Technologies that do not specifically utilize the Accessibility APIs,
and a standard method of piping data from a browser to offline processing tools
(such as a spellchecker, or download manager). It might also have other
benefits, such as for debugging, comparison with the output of other browsers
even if you can't run them to access their DOMs at the same time, or simply
because, as a single monolithic format, it can be used to reliably resume
reading, or to retransmit.

This actually sounds a bit too ambitious for an HTML5 deliverable, but it is an
idea.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Tuesday, 29 November 2011 14:59:53 UTC