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

Laura Carlson writes:
> 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.
> 

Actually, there's an unaddressed clash here between the long text
description type use case, and the IBM use of hidden that Rich has been
telling us about.

Laura correctly states the former. Users need to know that hidden
content exists, and get to decide whether to access that content.

In IBM's case authors make this decision and it's actually harmful for
users to access that content.

It would be harmful to support both use cases without further
distinction to clearly indicate which is which.

Janina

> 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

-- 

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 Wednesday, 12 September 2012 15:55:37 UTC