Re: Promise broken on ISSUE 204?

On Tue, May 8, 2012 at 10:22 PM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
> Benjamin Hawkes-Lewis, Tue, 8 May 2012 19:39:56 +0100:

[snip]

>> Accessibility-related content is relevant to the current application
>> state, not irrelevant. It should be usually be available when author
>> styles are not applied and images are not loaded.
>
> OK. You mean that it should then fallback to be visible. Is that the
> whole idea?

Yes, although without any implication that the fallback is always
worse than the author-styled alternative in which the same content is
presumptuously hidden.

> For whom would that be good or relevant?

It's hard to discuss without a concrete example where people think it
would be better to default to hiding content even when author CSS is
rejected and images are not loaded.

> * Not for users of ARIA supporting UAs, anyway: The ARIA support
> doesn't disappear just because CSS is disabled.

ARIA-supporting UAs are not required, or even encouraged, to render
labels and descriptions in @hidden to end users.

ARIA-supporting UAs are not required to expose structured or
interactive content in @hidden to accessibility APIs, only to flatten
associated labels and descriptions buried in @hidden to plain text.

> * And if, instead of @hidden, authors used aria-hidden="true" in
> combination with CSS, then, if CSS was disabled, the element would
> still be hidden, from assistive technology's point of view. (As you
> know, ARIA says that you MUST - unless you use a native feature, like
> @hidden - use aria-hidden='true' for hidden content.)

We cannot account for a requirement that is a mixture of the
ambiguous, the impossible, and the nonsensical.

> * It could be relevant for text browsers. But currently, I think none
> of them support @hidden. When they implement @hidden, then it could
> make sense.

The alternative technique of positioning content off-screen works with
text browsers today as well as tomorrow.

>> Content irrelevant to the current application state should *not* be
>> available when author styles are not applied, because its irrelevance
>> is not a purely stylistic issue. I think it makes sense, given its
>> original design, to place irrelevant content in @hidden.
>
> I agree that it makes sense to not use @hidden if the purpose is that
> it falls back to become visible when CSS is disable.

Hurrah.

> If so, perhaps it would be better to describe the ideal instead of
> forbidding anything

What do you mean and why would it be better?

> ... Also, if you want to forbid authors from doing
> it, then there is many more things that should be forbidden.

Assuming we should have any author conformance requirements at all,
there are indeed many more requirements that could and perhaps should
be mandated. Our poor coverage is not a great argument for being
liberal. It works as an argument for making broad author conformance
requirements that specify our goals, such as "All controls must have
an accessible name, calculated by algorithm X, that describes their
function". But when it comes to implementing those requirements in
conformance checkers, they will have to apply specific rules, like
"controls must not rely elements in @hidden to provide an accessible
name".

In this case, I'm even more worried what we are proposing to specify -
or more accurately, fail to specify, for UAs.

>> What I'm asking about is why we should support putting content
>> relevant to the current application state (such as labels and
>> descriptions applicable to visible content, or in Maciej's argument
>> whole navigable subtrees!) in an attribute originally intended to
>> designate content irrelevant to the current application state.
>
> Strictly speaking, "current state" means "any state". E.g. let's say an
> application has two states: You are not required to remove @hidden from
> any of the states.

I can't parse what you're saying here, sorry.

By "state" here, I mean things like:

a) State A: Form field is incomplete.
b) State B: Form field is completed but invalid. Show an error message
and a link to help.
c) State C: Form field is completed and valid.

@hidden is (or at least, was supposed to be) useful for allowing
authors to put the error message into the DOM while taking it out of
the representation of the document. When the application enters States
A or C, add @hidden to the error message and help. When the
application enters state B, remove @hidden from the error message and
help. In States A and C, it makes no sense to show the text when
author styles are not applied, expose the link in the accessibility
tree, or calculate the accessible description of the field using the
error message, even if @aria-describedby points to the @hidden
content.

>>> My question: Why can't this method be used in *combination* with
>>> @hidden? It seems at least John F's updated version of the change
>>> proposal, nothing would prevent you from doing that.
>>
>> Off-screen controls are included in the tab order, exposed the
>> accessibility tree, listed in enumerations of controls (e.g. JAWS link
>> list), available to skip commands, and are available to users who do
>> not apply author styles.
>>
>> Under the new proposal, @hidden controls wouldn't have any of these
>> advantages AFAICT.
>
> You said "when JS is available":
>
>>>> when JS is available, hide extra content off-screen but move it
>>>> on-screen if it receives focus?
>
> And JS can remove @hidden. But OK. I don't know exactly what you meant.
> Perhaps you meant CSS?

I was thinking of the case where you have a block of invisible content
inside which are controls that can receive focus. In that case you'd
normally want to make the block visible to contextualise the controls.
Until CSS4 Selectors, that requires JS. See the second example I gave
to David:

   http://lists.w3.org/Archives/Public/public-html/2012May/0061.html

>> If we're talking purely about UA conformance requirements *and* we
>> think authors are more likely to err by including content that should
>> be rendered in @hidden than expecting @hidden content to be rendered,
>> why don't we mandate that *if* content focus or interactive focus is
>> moved into a @hidden subtree, the hidden property should be removed
>> from the subtree until focus leaves again? I don't understand what
>> future leap of technology we're waiting around for here by leaving
>> behavior undefined.
>
> It is a pure author requirement that
>   <div id=i hidden tabinde=0>foo</div>
> shouldn't be made linked to via hyperlink. Since it can be linked to,
> it can also be made visible - and thus focusable - via CSS:
> *:target{display:block}. So we might see that authors makes a @hidden
> section visible and focusable.

Not reliably: the hiding of the content is style-independent (@hidden)
but the showing of the content is dependent on author styles. (I don't
think it makes to allow the non-rendering of @hidden to be overridden
with CSS, but that's by-the-by.)

Anyhow these capabilities seem orthogonal to whether we should mandate
UAs repair author abuse of @hidden as above. My real beef with
Maciej's objection is that it waters down the proposal to leave things
unspecified that we should either require or forbid.

--
Benjamin Hawkes-Lewis

Received on Tuesday, 8 May 2012 22:33:47 UTC