Re: Split Issue 30?

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


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

Screen readers have access to the DOM. But ARIA is fairly young, and 
common practices are still emerging.


>> Hidden content, whether referenced by ARIA attributes or not, cannot (should
>> not) support focusable content, as this throws of the long-held,
>> WAI-required need to maintain visible tab focus for sighted, keyboard-only
>> users (not just blind users, but any user unable to use a mouse):
> Does this mean that we should not be allowed to put rich content
> inside a<canvas>  too then? Since such content is hidden by the
> <canvas>.

The content is only hidden if it's marked display: none or @hidden. 
Otherwise, it's not hidden.

There's a patch for Mozilla in the works for Canvas; there's a 
preliminary patch for WebKit, and Microsoft did the right thing and 
supported a11y for Canvas in their first release.
Comparing Canvas to Img is the wrong way to go about things.

img has <area> and longdesc. Canvas has ARIA and the sub-tree. Canvas is 
more like Web Components.

Again, with Canvas, rich ARIA makes a lot of sense. ARIA makes the most 
sense when used by the scripting environment.
With IMG, we're looking at supporting a lot of existing and old content.

And again, longdesc is not the same, semantically, as aria-describedby.
aria-describedby and flowto require quite a bit more structure and work 
on the author.

Deprecating longdesc would dismantle a lot of work already out there and 
delay such work from being made accessible again.

I'm enthused that you're enthused about improving accessibility.

-Charles

Received on Friday, 10 February 2012 18:22:25 UTC