RE: FORMAL OBJECTION (was RE: Working Group Decision on ISSUE-204 aria-hidden)

Maciej Stachowiak wrote:
> I'm pretty sure I didn't suggest that. I don't think a mouth-stick user
> who is not visually impaired would ever be exposed to the link,

So then this technique is *ONLY* for visually impaired users? I want to be
clear on what is being exactly proposed, as to date apparently this
discussion seems to be clouded by some basic assumptions, one being that the
longer textual description, hidden from sighted users (using @hidden) but
semantically rich for visually impaired users, is being 'coded' only for
that user group: the technique does not provide *any* access to the same
content for sighted users.

> because
> they would not have access to the description. At least in Safari,
> aria-describedby is only ever exposed via output-side assistive
> technologies.

...with the exception (of course) to the monitor screen, which while also
output driven, is a different output technology that your statement suggests
people with disabilities would never use: Page Zooming isn't an assistive
technology, the ability to change screen contrast or load user-style sheets
are not assistive techniques/technologies, Visible focus of active elements
is not "assistive", etc. (Conversely this would suggest that VoiceOver is
*only* an assistive technology, that *only* people who are visually impaired
would use)

Maciej, in all sincerity and frankness, this is what you appear to be

Why should only a non-sighted user have access to the extended description?
Without a means for *all* users to access this content, you are creating an
artificial divide between sighted and non-sighted users with this technique.
Outside of the moral and legal ramifications of what this segregation might
suggest, it is at its very base a poor user experience for many sighted
users who may also benefit from longer rich textual descriptions.

Returning to a quote pulled from the Apple web site:

	"VoiceOver provides visual references to enable blind and sighted
users to work together on the same computer at the same time." 

...yet you have just suggested that a sighted user would never be exposed to
the longer textual description: 

	"I don't think a mouth-stick user who is not visually impaired would
ever be exposed to the link"

Which shall it be? How does this technique support Apple's own statement
that sighted and non-sighted users can work together on the same computer at
the same time?

This also opens up a whole other series of questions: 
* If the rich textual description can only be accessed with an ARIA aware
tool, how do authors test and maintain their output? 
* Would this content also be exposed to QA tools, such as link checkers?
There have been numerous concerns raised over the notion of "link-rot"
elsewhere (in the larger context of the @longdesc and other discussions),
yet this would appear on the surface to be feeding into that concern - if
the link-checker is not ARIA aware, it would respect the @hidden declaration
and not "see" the link(s) that would be in the @hidden longer textual
descriptions. It appears to me then that this would likely lead the
inevitable link rot others such as Ted O'Connor and Tantek Celik (to name
but 2) have referenced elsewhere.

* Following on with that line of question, what (if any) impact would this
technique have on SEO? Would not a longer textual description of an
info-graphic see SEO benefits from a text-based alternative? With the
current technique proposed, that content would (it seems to me anyway) also
be hidden from crawlers as well - unless we have evidence that Google, Bing,
Yandex (et al) are making their robots ARIA aware: remember that this
construct is seeking to make @hidden 'special' only for non-sighted users.
(I could imagine that the search engines would *NOT* want to index this
@hidden content, as when their sighted users went looking for the text their
search results suggest might be on a page it would not, in fact, appear on
the page unless you are using an ARIA aware tool.)

* If authors and QA tools cannot test their code without the assistance of
an ARIA aware tool, what incentive is there for them to create the code in
the first place?

Until such time as we accept that *any* user might want to have access to a
longer, rich text description of a complex image, and that *any* user
requires a "switch" to access that content (using any modality that they
can) we are failing. Creating a technique that includes a switch for
VoiceOver, but not for sighted users is an inequity that is counter to open
access of content on the web. 

On the bright side, you *are* thinking of how VoiceOver would provide a
switch to access or not access the richer content, and so this appears to be
on the right path. However, until such time that the sighted user is also
exposed to the possibility of accessing a longer textual description, as
well as a visible switching mechanism to act upon that choice, you have an
incomplete solution which fails Apple's own statement: "...enable blind and
sighted users to work together on the same computer at the same time."

This is true whether it is for @longdesc, or for this new technique.

> If we implemented the "encouraged" behavior, I would not
> expect that to change.

Thanks for the clarity.


Received on Wednesday, 15 August 2012 17:33:19 UTC