Re: Moving forward with Issue-204

May we please have a plain English version of the Details Section of
AllowAriaReferHidden so that we can better understand what the two
different CPs actually propose? We have previously made this request,
but are still awaiting its actualization.

I don't believe we can really discuss substance very accurately without
that--nor move to a survey, frankly.

Janina


Paul Cotton writes:
> 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
> 

-- 

Janina Sajka, Phone: +1.443.300.2200
   sip:janina@asterisk.rednote.net
  Email: janina@rednote.net

The Linux Foundation
Chair, Open Accessibility: http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair, Protocols & Formats http://www.w3.org/wai/pf
 Indie UI   http://www.w3.org/WAI/IndieUI/

Received on Monday, 11 June 2012 21:49:34 UTC