- From: Edward O'Connor <eoconnor@apple.com>
- Date: Fri, 08 Jun 2012 11:25:34 -0700
- To: public-html@w3.org
John wrote:
> The distance between the 2 positions will not dissipate by going to
> survey.
[…]
> As we have not yet heard from Jonas and Ted in response to the PW's
> feedback however[…]
Let me try to summarize the remaining differences between the current
Editor's Draft and the changes advocated in each proposal. For
reference, the current ED's text on hidden="" is here:
http://dev.w3.org/html5/spec/editing.html#the-hidden-attribute
== The Correct_Hidden_Attribute_Section_v3 proposal ==
The v3 proposal would remove two paragraphs immediately following the
first example, and would remove the second example. It then provides
replacement text. Putting aside for a moment some editorial issues with
the proposed changes[1], the normative changes in the v3 proposal amount
to the following:
1. The meaning of hidden="" is changed from "the element is not yet, or
is no longer, relevant" to "the element is not yet, or is no longer,
visible or interactive."
2. It removes the restriction that hidden="" elements "must not be used
to hide content that could legitimately be shown in another
presentation."
3. It replaces the restriction that "elements that are not hidden should
not link to or refer to elements that are hidden" with several other,
related restrictions (described below).
4. It adds the restriction that "Elements that are not themselves
hidden must not hyperlink to elements that are hidden." (This is
equivalent to half of the restriction removed in #3 above.)
5. It adds a normative restriction on the use of two WAI-ARIA
attributes, aria-flowto="" and aria-owns="". I note that the PFWG has
objected to such restrictions being present in HTML5, so this
provision may result in a Formal Objection being raised. [2]
6. It adds normative language allowing authors to use hidden="" elements
to provide descriptive text:
"However, 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>."
7. It adds normative language disallowing authors from using structured
content in hidden="" elements for providing descriptive text:
"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."
== The AllowAriaReferHidden proposal ==
The AllowAriaReferHidden proposal advocates reverting the change made in
r6980. This would result in several normative changes. In the list
below, I've tried to match up the numbers to the corresponding normative
changes in the other proposal; that's why some numbers are missing.
1. The meaning of hidden="" is changed from "the element is not yet, or
is no longer, relevant" to "the element is not yet, or is no longer,
directly relevant to the page's current state, or that it is being
used to declare content to be reused by other parts of the page as
opposed to being directly accessed by the user."
3. It replaces the restriction that "elements that are not hidden should
not link to or refer to elements that are hidden" with several other,
related restrictions (described below).
4. It adds the restriction that "Elements that are not themselves
hidden must not hyperlink to elements that are hidden." (This is
equivalent to half of the restriction removed in #3 above.)
5. It adds a normative restriction on the use of the for=""
attribute of <label> and <output> elements.
6. It adds normative language allowing authors to refer to hidden=""
elements in other (non-hyperlinking) contexts.
== Analysis of the relationship between the two proposals ==
1. This change is effectively equivalent in the two proposals.
2. The v3 proposal removes a normative statement that the
AllowAriaReferHidden proposal leaves in.
Should authors be allowed to use the hidden="" attribute "to hide
content that could legitimately be shown in another presentation?"
The following text added in the AllowAriaReferHidden proposal
clarifies the intent of this normative statement and makes it clear
that there's no conflict between it and the desire to reference
hidden="" content from aria-describedby="":
"While hiding the descriptions implies that they are not useful
alone, they could be written in such a way that they are useful in
the specific context of being referenced from the images that they
describe."
Thus, I believe that removing this normative statement is not
necessary for ISSUE-204.
3. Equivalent.
4. Equivalent.
5. Both add similar restrictions, but for different attributes.
The restriction on <label for> and <output for> seems necessary and
within the scope of HTML5.
The restriction on aria-flowto="" and aria-owns="" also seems
necessary, but the PFWG has made it clear that it would object to
such statements in HTML5.
6. AllowAriaReferHidden broadly allows authors to refer to hidden=""
elements for non-hyperlinking purposes, including scripting. It
provides several examples, including a use of aria-describedby="".
The v3 proposal more narrowly allows authors to refer to hidden=""
elements for descriptive purposes, and does not (explicitly) allow
the other cases allowed (such as scripting) allowed in the
AllowAriaReferHidden proposal.
The AllowAriaReferHidden proposal (or rather, an example added to the
spec by the revert proposed by AllowAriaReferHidden) provides a use
case for non-hyperlinking, non-descriptive referring to hidden=""
content:
"Similarly, a canvas element with the hidden attribute could be
used by a scripted graphics engine as an off-screen buffer, and a
form control could refer to a hidden form element using its form
attribute."
Given this use case, I believe the v3 proposal overly restricts
author behavior.
7. The v3 proposal explicitly disallows authors from using structured
content in hidden="" elements; the AllowAriaReferHidden imposes no
such restriction.
This was (one of the) main issues debated in the F2F discussion of
ISSUE-204. Neither proposal captures the compromise reached at the
F2F.
The author conformance change on which there was broad agreement (or
at least broad "can live with") at the F2F is require authors not
write content that, when flattened, loses essential meaning. But the
restriction in the v3 proposal goes far beyond that.
In mailing list discussion after the F2F Jonas suggested an alternate
restriction, not on authors but instead on UAs, that structured
hidden="" content not be flattened when exposed to AT. It has become
clear that such a requirement would be unacceptable to Microsoft.
I think there could be compromise language on this issue, which
simultaneously encourages (but does not require) UAs to expose the
full semantics of hidden="" content to AT, and that requires authors
to only use aria-describedby="" to refer to hidden="" content that,
when flattened, does not lose essential meaning. I encourage everyone
who has contributed text to both CPs to try to come up with such
compromise language on this point.
== Summary ==
The two proposals are very close to each other. In every case where they
still differ, the approach taken in the AllowAriaReferHidden proposal is
preferable. With the addition of suitable compromise language on the
flattening issue to the AllowAriaReferHidden proposal, I believe that we
could arrive at a point where the other proposal could be dropped and a
CfC issued.
Thanks,
Ted
1. It requests the redundant addition of three sentences, and requests
the removal of one sentence twice.
2. "The WAI Protocols and Formats Working Group strongly objects to any
RFC 2119 normative requirements on WAI-ARIA markup in HTML Working
Group specifications."
— http://lists.w3.org/Archives/Public/public-html/2012May/0156.html
Received on Friday, 8 June 2012 18:26:05 UTC