RE: [updated] proposed rewording of ISSUE-204 text

I support going with this for now and filing followup bugs for further refinement.

-----Original Message-----
From: Edward O'Connor [mailto:eoconnor@apple.com] 
Sent: Tuesday, September 11, 2012 4:53 PM
To: public-html@w3.org
Subject: [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 Wednesday, 12 September 2012 01:58:16 UTC