[Accessibility-atspi] Re: [Accessibility] Two diffferent ATK implementations for HTML document structures

Wed Mar 1 21:13:29 PST 2006

> If you think there is an emerging consensus about semantic differences
> between "labelled" and "described", I would think RELATION_DESCRIBED_BY
> would be a natural addition to the ATK/AT-SPI set.

We would also get RELATION_DESCRIPTION_FOR right?

There is a consensus now. We have a separation between label and 
description in both DHTML accessibility and newly emerging standards for 
exposing relations on Windows using accNavigate. A description is 
help/hint text, which may or may not be spoken.

> That seems correct to me, i.e. the left hand label applies to the right
> hand UI component.  So I guess I would be one of those people who would
> apply "LABELLED_BY" in this case.

What if it's a different widget than a button? What if you want to expose 
the labelledby relationship as a rich content subtree instead of just a 
piece of text and you still have a separate description. What if you have 
both a DHTML labelled_by and described_by relation you want to expose

[ ] Use the Star flag for emails untouched for ____ days
The star flag can be used to collect unread emails in danger of being 
ignored.

Checkboxes are no the only widgets which could have a complex subtree for 
a label.

Reasons for needing description:
- In some cases the label is a complex subtree which includes the current 
text for another input field
- A description may or may not be spoken by a screen reader depending on 
the verbosity
- The screen reader may choose to implement a "more information" or 
"describe this" key which needs to know where the description is
- Screen readers will often choose to read the label first, then the 
widget type, and then finally the description (most important to least). 
This allows the user to shut the screen reader up as soon as they hear 
what they need.

- Aaron

Aaron Leventhal
IBM web accessibility architect
Voice: 781-583-4083
Tie line: 364-5945
http://www.mozilla.org/access

Bill Haneman <Bill.Haneman at Sun.COM> 
03/01/2006 04:40 PM

To
Aaron M Leventhal/Cambridge/IBM at IBMUS
cc
Peter Korn <Peter.Korn at Sun.COM>, accessibility-atspi at freestandards.org, 
accessibility at freestandards.org, 
accessibility-atspi-bounces at freestandards.org
Subject
Re: [Accessibility-atspi] Re: [Accessibility] Two diffferent ATK 
implementations for HTML document structures

On Wed, 2006-03-01 at 10:32, Aaron M Leventhal wrote:
> I can answer some of these:
> 
>   <p>You <em>are</em> a nice person.</p>
> In that case (and for many elements) we'll be looking at the element
> to see if there is any reason we need to create an object for it. If
> for some reason someone made it focusable, created actions for it, or
> created relations for it, then it needs it's own node. Otherwise we
> can just use the CSS to describe the text attribute run.

I agree; this seems like the intended use of AccessibleText's
TextAttributes API.  As Peter points out, keeping what semantics are
available seems desirable, even if that means "redundant" attributes,
i.e. both "css:font-style=italic" and "em" (not sure the right namespace
for the latter).

> The image file name would be exposed for the case where there is no
> alt or title for an image, and the screen reader needs to make
> something up via a heuristic. 

There's another way in AT-SPI to do this; if images implement
StreamableContent (which ultimately we expect/intend/hope they will),
then StreamableContent provides not only for getting the backing data,
but for getting a URI which in most cases would include the filename.

> On the other hand, I have some code that's about 95% finished which
> does a better job at this than a screen reader could ever do. If we
> use that I don't think we need to expose the file name for images. The
> code I'm talking about can grab the title of a page pointed to by an
> image link, and use that for the name of the image. It also has some
> other smarts for creating a name if that doesn't work. This could help
> for sites like Target where they don't do alt text correctly. On the
> other hand, it seems like Target puts a generic repetitve incorrect
> alt text on everything, which is even worse. Unless the alt attribute
> is missing we don't know we should make something up.
> 
> The problem is that it doesn't line up with DHTML accessibility, where
> we have both a labelledby and describedby relation, which are
> distinct. A description is more like text that gives additional,
> potentially crucial, information about a form control or othre element
> on a page. The label is just the basic text for it.

If you think there is an emerging consensus about semantic differences
between "labelled" and "described", I would think RELATION_DESCRIBED_BY
would be a natural addition to the ATK/AT-SPI set.

> 
> Here's an example from the Firefox options menu (first tab):
> 
> |-------------------------- Default browser
> -----------------------------------------------|
> | 
> |
> |  Determine how Firefox connects to the internet               [
> Connection settings ]    |
> | 
> |
> 
|------------------------------------------------------------------------------------------|
> 
> I suppose someone might argue with me on this that "Connection
> settings" is just the name and therefore the labelledby relation is
> still available. 

That seems correct to me, i.e. the left hand label applies to the right
hand UI component.  So I guess I would be one of those people who would
apply "LABELLED_BY" in this case.

> However, you could do this for another control where the label needed
> to be called out with a relation, and there was some specific hint
> description text for that control. Labels and descriptions are just
> distinct, especially in DHTML accessibiliy, and we want to clearly
> document that description is really like in-the-dialog help text.

Bill

> - Aaron

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/accessibility/attachments/20060302/ba985e43/attachment.htm