[Bug 13668] Generated content must be accessible

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

--- Comment #3 from Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> 2011-08-04 06:32:45 UTC ---
(In reply to comment #0)
> The HTML5 spec should clarify that generated content should be included in the
> DOM,

It is included in the CSS Object Model not the DOM, and out of scope for HTML5:

    http://dev.w3.org/csswg/cssom/

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

    window.getComputedStyle(el, '::before').content

> available to assistive technology

HTML references WAI-ARIA which defines text exposed to accessibility APIs to
include generated content "as appropriate":

    http://dev.w3.org/html5/spec/content-models.html#wai-aria

    http://www.w3.org/WAI/PF/aria/roles#textalternativecomputation

There are problems with this of course. See in particular this www-style
thread:

    http://lists.w3.org/Archives/Public/www-style/2010Nov/0313.html

Note also PFWG's view that this "It is ultimately up to a group working on CSS
to define the accessibility API mapping of that information when applied to a
host language."

   
http://lists.w3.org/Archives/Public/public-pfwg-comments/2010OctDec/0017.html

So again, this seems out of scope for HTML5.

> and copied to the clipboard along with other content.

That requirement is unrealistic because it's unclear what we should standardize
and browser vendors want to continue to experiment with the right behaviours
for copy and paste:

    
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-February/030182.html

> Use case: Nadia's screen reader is reading her a document, but it doesn't make
> sense because the browser does not expose generated content, and thus the
> screen reader cannot detect or voice the explanatory text such as "Example:",
> "Note:", and "Warning:" added before the paragraphs.

I think this accessibility failure reflects authorial misuse of CSS for
content.

This text would be lost if author styles were replaced with user agent or user
styles, so I think such code violates WCAG2 1.3.1:

    http://www.w3.org/TR/WCAG20/#content-structure-separation-programmatic

WAI-ARIA warns against this practice: "Note: Though the user agent may make
efforts to compute a text alternative from CSS-generated text in the absence of
text content determinable from the DOM, authors should not provide text through
a style sheet, as the user agent may incorrectly determine the text
alternative."

However, authors continue to abuse generated content. For example, the HTML5
spec itself abuses CSS to insert the text "This box is non-normative.
Implementation requirements are given below this box" on content with the class
"domintro".

> Use case: Ralph has difficulty entering text, so he relies on copy and paste
> more than most users. However, when he selects and copies a web page includes
> lots of numbered list items, then pastes it into email, all the item numbers
> are replaced by hash signs. Because editing the text is difficult for Ralph, it
> is much more of a problem for him than for other users who can correct the
> errors more easily.

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

    http://www.w3.org/TR/REC-html40-971218/struct/lists.html#h-10.3.1

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

> Note that it should still be possible to distinguish generated content from
> author-supplied content.

Can you be more specific about this requirement? Distinguish it in what
context? Do you mean it should be distinguished in the platform accessibility
APIs? If so, I suggest taking that up with PFWG for a future version of
WAI-ARIA.

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

Received on Thursday, 4 August 2011 06:32:49 UTC