[Bug 12243] Conformance of aria-describedby="" and aria-labelledby="" attributes pointing to interactive content

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12243

--- Comment #14 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 2011-06-11 22:08:45 UTC ---
(In reply to comment #12)
> Ok, so it seems like we agree that the ARIA spec does not prescribe that the
> elements pointed to by aria-describedby should be treated as just their
> textnodes concatenated. Exposing the semantics of the elements it points to is
> allowed.

Yes, ARIA has some encouragement to reveal markup semantics:

ARIA 1.0 says (http://www.w3.org/TR/wai-aria/complete):

landmark (abstract role)
#
A region of the page intended as a navigational landmark.
Assistive technologies SHOULD allow the user to quickly navigate to 
landmark regions. Mainstream user agents MAY allow the user to quickly 
navigate to landmark regions.

ARIA implemenation says: (http://www.w3.org/TR/wai-aria-implementation/)

Note that aria-describedby may reference structured or interactive 
information where users would want to be able to navigate to different 
sections of content. User agents MAY provide a way for the user to 
navigate to structured information referenced by aria-describedby and 
assistive technology SHOULD provide such a method.


But I still think the issue described in comment #0 is important, and related
to - for instance - the importance that the HTML5 work has placed on uniformity
between browser due to the fac that authors typically only test in a single web
browser. 

Likewise, if one AT presents markup, while another present 'string', and an
author is testing in only an AT which presnts it as string - or only as markup,
then it is likely that the content pointed to by ARIA will be work suboptimal,
in that kind of AT that  does not work like the one the author was testing.

E.g. imagine that aria-describedby points to a table - user experience will be
completely different depeninding on whether the AT present it as mark-up or as
'string'.

HTML5 ought to put as much weight on uniformity in this field as in other
fields, no?

> As for aria-labelledby, it sounds like you are doing an awful lot of
> interpretation. First off, saying that "text alternative" automatically means
> that it has to be a string that doesn't contain semantics is a stretch to me. 
> Why couldn't "text" as opposed to for example visual images?
> 
> Are you basing your interpretation on something I'm missing?

My interpretation is based on experience with how AT is presenting ARIA. But
also on the ARIA specifications, which uses special encouragmeent language -
SHOULD - whenever it wants to emphasize that markup semantics could be
presented.

That said: For the IMG element, then if the IMG is kept inside e.g. <strong>,
then the words in the @alt should probably be presented with strong emphasiz.
At least if the IMG could be given role=text (this is a role that Steve
proposed in wai-xtech@ recently.) That's an example of where structural markup
merely provides a presentational enhancement. But if aria-labelledby points to
e.g. a table, then it would constitute the same problem as if aria-describedby
did it - see above about the probelms whenever AT interpret the same thing
differently. Even for @longdesc we have this: one of the arguments against
@longdesc is not every AT or browsers presents it to the user, leading to
different experience etc.

> Also, I agree that step 2.C says that the textual content of an element is the
> textual contents of its children concatenated. However that step doesn't say
> how to build the text contents of the children, so it could certainly include
> the semantics of the children. Also, step 2.C only applies if step 2.A and 2.B
> hasn't yielded anything, and I those are the steps that bring up semantics.

Sometimes it is useful to present things as text, compared to mixing in further
semantics. It is not completely clear to me what you have in mind. But let me
take an example: 

AT currently have poor support for the OBJECT element, they don't read the
fallback, typically. However, by pointing to the OBJECT element with
aria-describedby, then one can make the AT read that content. Currently, this
means that the content is read as a string. Which is already progress. But what
if the fallback is a table that represents a graphical representation of the
same data? It would then be great if it was possible to make AT read it as
table. That said: the very best thing would have been if AT simply interpreted
the OBJECT correctly. 

The most important argument against presenting the content of aria-describedby
as structured text is, IMHO, the issue of interoperability. Authors must be
given clear guidance about how it works, and must be able to expect how it is
to be intepreted and presented. 

But a quite good argument in favor of presenting it as markup, could be this:
Steve has said that at least one AT developer wants the browser to do all the
dirty work. And clearly, if the content is interpreted as markup, then browsers
already have ways to handle markup, obviously.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Saturday, 11 June 2011 22:08:51 UTC