Re: Split Issue 30?

ing aria-describedby for long text descriptions is a dead issue from the
PF's perspective.

Attempts so to do overload describedby. That's unacceptable.

Even should it prove there's some way by which browsers might pass
marked up content to the a11y APIs so that these APIs will not flatten
that content to straight text, describedby still does not meet the
requirements of a long text mechanism. Specifically, describedby is
intended for content that is to be read automatically as it is
encountered. Our long text requirements are the exact opposite, as we
have stated again, and again, and again, and again. What part of this
requirement is failing to sink in?

As of this writing there is no workable mechanism in HTML 5 for long
text descriptions. And, there is only one workable proposal on the
HTML-WG's plate.


Janina

Jonas Sicking writes:
> On Fri, Feb 10, 2012 at 10:21 AM, Charles Pritchard <chuck@jumis.com> wrote:
> > On 2/10/2012 9:45 AM, Jonas Sicking wrote:
> >>
> >> On Thu, Feb 9, 2012 at 12:16 AM, John Foliot<john@foliot.ca>  wrote:
> >>
> >>> (even though, as I have discovered via limited testing, what is
> >>> being pointed to is returned back as null content to in the screen
> >>> readers I
> >>> tested, which is currently correct behavior) - the point being it is not
> >>> specifically disallowed as far as I can see.
> >>>
> >>> What is at issue is what happens to content not visible on screen: the
> >>> Accessibility APIs flatten the content to string text,
> >>
> >> Note that no-where in the HTML spec does it say to treat @hidden, or
> >> otherwise invisible, elements differently. I.e. there are no
> >> difference in the normative requirements for an aria attribute that
> >> points to a @hidden element, from one that points to a non-hidden
> >> element. Hence I would expect them to behave the same. (Similarly, the
> >> spec doesn't say that browsers should behave differently on thursdays,
> >> hence I would expect browsers to behave the same on thursdays as it
> >> does on fridays).
> >
> >
> > "The hidden attribute is a boolean attribute. When specified on an element,
> > it indicates that the element is not yet, or is no longer, relevant. User
> > agents should not render elements that have the hidden attribute
> > specified... The hidden attribute must not be used to hide content that
> > could legitimately be shown in another presentation... It is similarly
> > incorrect to use this attribute to hide content just from one presentation —
> > if something is marked hidden, it is hidden from all presentations,
> > including, for instance, screen readers."
> > http://www.w3.org/TR/html5/editing.html
> 
> Good point. I've updated my change proposal to change this text appropriately.
> 
> Thanks!
> 
> >> I'm happy to modify my change proposal to make this explicitly clear.
> >> I.e. add a normative requirement that says that browsers MUST expose
> >> the full semantics the description pointed to be aria-describedby,
> >> even when @hidden.
> >
> > We have aria-flowto as well.
> 
> This should be covered by my change proposal now. Though it's
> technically separate from ISSUE-30.
> 
> > Screen readers have access to the DOM. But ARIA is fairly young, and common
> > practices are still emerging.
> 
> I'm not sure how this is relevant to this thread? If I'm missing
> something, please elaborate.
> 
> / Jonas

-- 

Janina Sajka, Phone: +1.443.300.2200
  sip:janina@asterisk.rednote.net

Chair, Open Accessibility janina@a11y.org 
Linux Foundation  http://a11y.org

Chair, Protocols & Formats
Web Accessibility Initiative http://www.w3.org/wai/pf
World Wide Web Consortium (W3C)

Received on Monday, 13 February 2012 20:23:00 UTC