Re: Finalizing an Issue-204 CP

On Fri, Apr 20, 2012 at 12:25 AM, Cynthia Shelly <cyns@microsoft.com> wrote:

http://www.w3.org/html/wg/wiki/Correct_Hidden_Attribute_Section_v2#Accessibility_API_mappings

I have a lot of doubts about the general intent of the CP, but in this
email I just want to give some feedback on the proposed text for the
spec.

Proposed text:

"@hidden is equivalent to the CSS display:none construct."

This isn't good normative text. What does "equivalent" mean here? For
instance, does it mean @hidden is an authorial presentational
suggestion rather than semantic markup critical to the meaning of the
content?

Proposed text:

"For example, it would be incorrect to use the href attribute to link
to a section marked with the hidden attribute."

The WHATWG text establishes the authoring conformance requirements
much more clearly:

"Elements that are not themselves hidden must not hyperlink to
elements that are hidden. The for attributes of label and output
elements that are not themselves hidden must similarly not refer to
elements that are hidden."

I suggest adopting that language wholesale, modulo the label element
if we want to allow that.

"It would similarly be incorrect to use the ARIA aria-flowto or
aria-owns attributes to refer to descriptions that are themselves
hidden, as these elements are not available to the user."

This suffers from the same unclear language ("incorrect" rather than
"must not"). Also, shouldn't this be defined by normative text in ARIA
not HTML5 - authors should not set the targets of these properties to
elements with the aria-hidden property?

Proposed text:

"Since the content is not rendered, linking to it would have
unpredicatble behavior, either dropping the user at a location with no
rendered content, or failing to navigate."

"unpredictble" is misspelled.

Specifications make the behavior predictable, invalidating this
rationale. HTML and CSSOMView currently define that a navigation
action occurs (history changes etc.) but the viewport is not scrolled:

http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#scroll-to-fragid

http://dev.w3.org/csswg/cssom-view/#element-scrolling-members

Perhaps what you mean is that this behavior is unexpected by the user?

Proposed text:

"Any structure in the referenced element, including headings, links,
tables, paragraphs, and form elements, will be lost. The text children
of the element will be flattened to a string. As such, authors should
only use this technique for string content. At the time of this
writing, some screen reader products will read both the accessible
name and accessible description, so authors should take care with the
length of text provided via this method."

These drawbacks apply to @aria-labelledby and @aria-describedby for
non-@hidden content too, so this text doesn't belong in guidance for
@hidden. (You could perhaps note that @hidden makes navigation to
labelling and describing elements impossible.)

What does "authors should only use this technique for string content"
mean?  e.g. Is this supposed to discourage marking up descriptions
with microdata, for example? Why is it a "should" not a "must"? What
we want is for the accessible name and description calculated from the
markup to be good names and descriptions. That's not the same as
avoiding semantic markup (e.g. RDFa, microdata, language change
indications).

--
Benjamin Hawkes-Lewis

Received on Friday, 20 April 2012 09:32:58 UTC