[updated] proposed rewording of ISSUE-204 text

Hi all,

On Monday I posted about our proposed new text to address problems
identified with the text adopted by the WG in the ISSUE-204 decision.[1]
Here is a small revision of that text which attempts to address several
of the concerns that have been raised in Bugzilla[2] and here on
public-html:

> Accessibility APIs are encouraged to allow a way to expose structured
> content while marking it as hidden in the default view. Such content
> should not be perceivable to users in the normal document flow in any
> modality, whether using Assistive Technology or mainstream User
> Agents.
>
> When such features are available, User Agents may thus expose the full
> semantics of hidden="" elements to Assistive Technology when
> appropriate, if such content is referenced indirectly by an ID
> reference or hash-name reference. This allows Assistive Technologies
> to access the content structure upon user request, while keeping the
> content hidden in all presentations of the normal document flow. Some
> examples of where it would be appropriate for the structure of
> hidden="" elements to be exposed to users of AT with such an API
> include:
>
>  * a <map> referenced from <img usemap>
>  * table headers referenced with the headers="" attribute
>
> Cases where it would be inappropriate for the structure of hidden=""
> elements to be exposed to users of AT with such an API include:
>
>  * a hidden="" element referenced by <a href> within the same document
>  * a hidden="" form element referenced by <label for>
>    Note: The sorts of elements referenced from <label for> cannot be
>    flattened without losing essential meaning (see below).
>
> Other specifications which define elements and attributes which may be
> included in valid HTML documents (such as SVG, MathML, and WAI-ARIA)
> may define how or whether this applies to their elements and
> attributes.
>
> Because historically some User Agents have flattened hidden content
> when exposing such content to Assistive Technology, authors SHOULD NOT
> reference hidden="" content which would lose essential meaning when
> flattened.

Changes (with rationale) described below.

Leif wrote, in [3]:

> Summarized, we could say that Ted’s new text recommends that, in case
> of indirect relations between hidden *labels/captions* and some
> visible content then the hidden label/caption content should be
> exposed. Whereas when visible label/caption content reference hidden
> *content*, then the hidden content should not be exposed. Could a
> summary along those lines be added to the text?

I'm not sure that accurately captures the principle at heart, but I've
tried to rework the text a bit to make it more clear.

> (3) I think the text 
>       """Cases where it would be inappropriate include""" 
> should be congruent with the text about when it *would be* approriate.
> For example like this:
>       """Cases where it would be inappropriate for the structure
>          of hidden="" elements to be exposed to users of AT with
>          such an API include"""

Done.

> (4) Regarding the negative examples, then they should be described
> more congruently with the positive examples.

Done.

John constructed an example in [4] which used <td headers> to point at a
<th hidden> containing an <a> element. I think this wouldn't be
conforming, due to the language stating that "authors SHOULD NOT
reference hidden content which would lose essential meaning when
flattened." But I had apparently failed to preserve that sentence in the
new text. Sorry about that! Fixed.

John wrote:

> 1) If the emergent spec is prepared to provide an itemized list of
> what semantic constructs can be exposed (and thus are conformant, such
> as <span> or <th>) versus those that are not (such as a hidden <a>
> element) - i.e, something more definitive than "Cases where it would
> be inappropriate include..." then I think that might be one path
> forward.

As Maciej pointed out in [5], "generating a complete and correct list
would take considerable time." Given that the original ISSUE-204 text
only had one example and not an exhaustive list, I think we can improve
the text now and add a comprehensive list later, in a followup bug.

> 2) The other is to specifically mandate User Agents that when an <a>
> element is referenced, that is normally "hidden", that the UA
> subsequently present that link visually for those users that so need.

This sounds interesting. Do you have a suggestion for how to word such a
mandate? I think we might be able to come up with something you and I
can both live with.

> As one of those who "FOed" this proposal, I have now tried to offer 2
> potential solutions to address the concerns I have.

Thanks! :) I really appreciate everyone trying to work the remaining
technical issues here.

I'm pretty happy with the above text. It could be made better, but I
think it's so much better than what's in the spec that I'd rather go
with this now & address further tweaking in followup bugs. Given that,

* Does anyone object to proceeding with the above version of the text?

* Alternately, do you support going with this for now & filing followup
  bugs for further refinement?


Thanks,
Ted

1. http://lists.w3.org/Archives/Public/public-html/2012Sep/0141.html
2. https://www.w3.org/Bugs/Public/show_bug.cgi?id=18744
3. https://www.w3.org/Bugs/Public/show_bug.cgi?id=18744#c14
4. http://lists.w3.org/Archives/Public/public-html/2012Sep/0146.html
5. http://lists.w3.org/Archives/Public/public-html/2012Sep/0148.html

Received on Tuesday, 11 September 2012 23:53:08 UTC