Issue 204 / Correct Hidden Attribute Section v4 (was RE: Moving forward with Issue-204)

Edward O'Connor wrote:
> 
> 
> == 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.

I have re-visited the AllowARiaReferHidden proposal [1] looking for that text, and cannot find it anywhere. Upon discussion of this point in the Text sub-team call, we believe that this sentence does not add any substantive value to either proposal. Further, "hidden" descriptions of an image can be useful alone, and so there is no apparent issue at hand.



> 
> 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.

The ARIA Candidate Recommendation and the Draft WAI-ARIA 1.0 User Agent Implementation Guide [2] are both work products of the Protocols and Formats Working Group, and is I believe, out of scope for another Working Group to impose restrictions upon. Feedback on the Draft UAIG should be submitted to PFWG.



> 
> 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.

Once again, I do not see any reference to this statement in the AllowAriaReferHidden proposal; however Jonas did write:

 "Exposing the rich semantics of contents inside a <canvas> in Firefox will take a lot more than changing what object <canvas> inherits from. Whatever solution we come up with for that can hopefully be reused to expose the rich contents of @hidden elements exposed through aria-describedby."

Given that how to do that today is still unclear, authors SHOULD be discouraged from creating content that cannot be acted upon. Should a solution emerge at some future date, then the existing proposed restriction could be revisited, either as part of a second Last Call, or as part of HTML.next.

(As well, creating accessible content that is associated to <canvas> content is not the same as @hidden content - it may not be exposed to sighted users, but that is because they see the canvas instead.)


> 
> 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.

This appears to be the core area of disagreement. 

I have tried to address Ted's concerns, and have added the following proposed text to a new V4 Draft Proposal: http://www.w3.org/html/wg/wiki/Correct_Hidden_Attribute_Section_v4  

 "Authors SHOULD avoid using 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, as noted above in the ARIA API mappings<linked>. If a (scripted) mechanism is used to render the hidden content on-screen (on demand) so that sighted and non-sighted users can effectively interact with the structured content, then authors MAY provide structured content in this scenario."


At issue is the desire to avoid encouraging authors to create content for which there is no effective solution at hand today. *IF* at some point an effective mechanism emerges that addresses all of the requirements of WCAG (2.4.7 Focus Visible: including a visual indication of *all* tab-stops [3]) *THEN* the use of hidden structured content MAY be used: Minus that key piece then the problems noted in the ARIA API mappings [4] would remain.

I encourage others to review this change, and welcome further feedback.

JF

[1] http://www.w3.org/WAI/PF/aria-implementation/ 
[2] http://www.w3.org/html/wg/wiki/ChangeProposals/AllowAriaReferHidden 
[2] http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-visible.html 
[3] http://www.w3.org/html/wg/wiki/Correct_Hidden_Attribute_Section_v4#Accessibility_API_mappings

Received on Tuesday, 26 June 2012 21:40:43 UTC