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

Hi Ted,

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

It is crucial to agree upon a list before ISSUE-30 is taken up.
Leaving it undefined will inevitability lead to problems.

Another requirement would be to state in the spec that hidden content
MUST be discoverable to ALL users and provide examples with
illustrations for how browser vendors can do this in the rendering
section. i.e. like the new spec text for longdesc.

Best Regards,
Laura

-- 
Laura L. Carlson

On Tue, Sep 11, 2012 at 6:52 PM, Edward O'Connor <eoconnor@apple.com> wrote:
> 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
>



-- 
Laura L. Carlson

Received on Wednesday, 12 September 2012 13:22:12 UTC