- From: <bugzilla@jessica.w3.org>
- Date: Tue, 29 Nov 2011 14:59:50 +0000
- To: public-html-a11y@w3.org
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