RE: Moving forward with Issue-204

Ted's analysis is very useful since it identifies the difference between the two current change proposals.

>7. The v3 proposal explicitly disallows authors from using structured content in hidden="" elements; the AllowAriaReferHidden imposes no such restriction.
...
> I encourage everyone who has contributed text to both CPs to try to come up with such compromise language on this point.

The Chairs would like to encourage the authors  of the two proposals for ISSUE-204:
http://dev.w3.org/html5/status/issue-status.html#ISSUE-204

and any other WG members to work on eliminating the differences between the two proposals identified by Ted's analysis AND especially the item 7 described above.

> With the addition of suitable compromise language on the flattening issue to the AllowAriaReferHidden proposal,

The Chairs would like to propose that the above work be done BEFORE tackling the flattening issue since it appears we will not get consensus on this matter unless everyone can accept a MAY provision.  

/paulc

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329


-----Original Message-----
From: Edward O'Connor [mailto:eoconnor@apple.com] 
Sent: Friday, June 08, 2012 2:26 PM
To: public-html@w3.org
Subject: Re: Moving forward with Issue-204

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 Monday, 11 June 2012 21:07:28 UTC