W3C home > Mailing lists > Public > public-html@w3.org > January 2012

Re: Revert Request

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Fri, 27 Jan 2012 11:42:01 +0100
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Cc: John Foliot <john@foliot.ca>, Paul Cotton <Paul.Cotton@microsoft.com>, Laura Carlson <laura.lee.carlson@gmail.com>, Sam Ruby <rubys@intertwingly.net>, Maciej Stachowiak <mjs@apple.com>, HTML WG <public-html@w3.org>
Message-ID: <20120127114201461598.55eaae18@xn--mlform-iua.no>
Silvia Pfeiffer, Fri, 27 Jan 2012 17:14:49 +1100:
> On Fri, Jan 27, 2012 at 4:56 PM, John Foliot wrote:

>> Justification: as has previously been brought forward to the Working 
>> Group [1][2], hidden text (i.e. text not visible on screen) is 
>> flattened to string text _per the various Accessibility APIs_

Per ARIA, the 'flattened to string' issue is linked to the use of 
@aria-describedby/@aria-labelledby. Any content that is referenced via 
@aria-describedby, is 'flattened to string text'. Thus, 'flattened to 
string text' is not linked to @hidden in any way, AFAICT.

> Maybe the a11y APIs need an update - since they, too, need to cope
> with the challenge of the changes that have been made to HTML. I don't
> think it's unreasonable to expect certain inconsistencies to emerge in
> those tools that will need to be fixed.

On the subject of APIs: Another way to describe what *currently* 
happens in APIs, is to say that the @aria-describedby referenced text 
*picks up* the mark-up features of the element from which it is 
referenced. Consider this example:

   <img lang=en aria-labelledby=desc >
   <h1 hidden lang=de id=desc >Das Bild</h1>

Then, here 'Das Bild' would be read as if it was the @alt text for the 
img element. Thus, it is a bit like the how the 'Paste and Match Style' 
option in the Mac OS X TextEdit.app, for instance, works. And, thus, 
the 'flattened to string' could seen as a feature rather than a 
problem, and the problems related to the #desc element being in German, 
for instance, could be seen as an authoring issue: The author should 
see to that aria-labelledby/-describedby points to a same language 
resource.

And therefore, there could be risks related to simply 'turning on' the 
mark-up features of content referenced via @aria-labelledby, as 
suggested by Jonas in his CP. For instance, in the example above, it 
could be very confusing if the 'heading-ness' of the h1 element was 
announced.

Jonas' CP claims that ARIA recommends that content referenced via 
aria-describedby, should be revealed to the user. However, he does not 
point to any section in ARIA to justify that claim. The WAI-ARIA 1.0 
User Agent Implementation GUide says: [*]

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

I guess this boils down to 'UAs/ATs may/should allow users to use 
links, buttons, ToCs etc that occur inside @aria-describedby referenced 
area'. I.e. not much detail. And also, not clear what if the very 
element referenced itself is a link. 

[*] 
http://www.w3.org/TR/wai-aria-implementation/#mapping_additional_relations_reverse_relations
-- 
Leif Halvard Silli
Received on Friday, 27 January 2012 10:42:45 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:29 UTC