Re: 48-Hour Consensus Call: Updated Issue-204 Change Proposal

On Wed, May 9, 2012 at 7:50 PM, Janina Sajka <janina@rednote.net> wrote:
> As usual, if there is objection in the Task Force to such a consensus
> position, please respond by replying to this message no later than close
> of business, Boston Time, on Friday 11 May.

Me again (sorry).

I object because:

1. It's not been shown that authors are more likely to mark content
@hidden and expect it to be rendered than they are to mark content
@hidden and expect it to be hidden. So it's not obvious that we should
expect user agents to try to honor references to hidden content.

2. It's sometimes said that ARIA requires this, but that's not really
true, since (a) HTML is free as a host language to define the text
alternative implied by @hidden's semantics and (b) ARIA's
implementation guide says (informatively) that user agents should not
put aria-hidden content into the accessibility hierarchy except as
required when computing text alternatives.

3. No concrete examples have been given where the proponents would
like @hidden content to be rendered and where this would provide
either the same user experience with simpler existing techniques
(aria-label) or a better user experience with techniques that work
today (CSS off-screen positioning). So even if we want user agents to
honor references to hidden content it's not obvious we should make
such markup conforming.

4. Rationales should feature examples that _act_ as rationale rather
than presume rationality but the examples given in the Change
Proposal's rationale have poor usability and maintainability
characteristics. Example 1 still features an image where (AFAICT) the
accessible name would compute to ASCII gibberish, seemingly
demonstrating this markup pattern is beyond even expert authors.
Example 2 would be much more simply authored with @aria-label. Example
3 is self-confessedly "not a great piece of UI design".

5. How to apply the editorial changes in Details is unclear. For
example, they include the text "All HTML elements may have the hidden
content attribute set" in the text to be added, even though in the
draft this comes a couple paragraphs before the text to be removed.
It's not obvious if the intent is to delete the "skeletal example"
given in the HTML5 spec or not.

6. The HTML5 spec has "it would be incorrect to use the href attribute
to link to a section marked with the hidden attribute. If the content
is not applicable or relevant, then there is no reason to link to it."
The Change Proposal replaces this with: "Since the content is not
rendered, linking to it would result in behavior the user does not
expect, either dropping the user at a location with no rendered
content, or failing to navigate." This contradicts the HTML5 spec,
which fully defines the result (navigation occurs, but the user agent
does not bring the hidden area to the user's attention, for example by
scrolling it into view). For a detailed walk-through of the spec on
this point, please see:

    http://lists.w3.org/Archives/Public/public-html-a11y/2012Apr/0166.html

7. The proposed text includes "hidden elements MAY be used to provide
descriptive text if such content provides a good user experience, by
using aria-describedby and aria-labelledby and HTML labelling elements
such as <label>, <legend>, <caption>, and <figcaption>." The only
reason for introducing this text at all is to provide guidance for web
authors, but this text is too vague to be helpful. How does a user
know whether they have provided a "good user experience" or not? I
think the actual end-user requirement here is best expressed by WCAG
1.1. If we're going to list HTML labeling elements that count for
these purposes we should provide an exhaustive list rather than just
examples.

8. "Authors SHOULD NOT use hidden elements for longer content that has
structured text (e.g., headings, anchors, list markup, table markup,
etc.), as some user-agents/AT will flatten the referenced elements to
plain text, losing interactivity and semantic structure." This has
nothing to do with @hidden, this is the effect of computing an
accessible name or description, and it's very confusing to authors and
damaging to web accessibility to imply it has anything to do with
@hidden. The relevant point with @hidden is that it's not clear how
UAs should allow navigation with or interaction with content in
@hidden, so the ARIA implementation guide (informatively) says they
should not create objects in the accessible hierarchy for such
content.

9. If we think it's realistic for UAs and AT to provide pointers to
structured/interactive descriptions without simultaneously reducing
them into a plain text property, we should require that rather than
pretend this is beyond our technical knowhow.

10. If we think it's realistic for UAs and AT to expose hidden content
for navigation and interaction when it receives content focus or
interactive focus, we should require that rather than leave them to
read between the lines to see this is allowed.

I'd better stop writing before I think of more reasons to object. ;)

--
Benjamin Hawkes-Lewis

Received on Wednesday, 9 May 2012 19:45:18 UTC