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

[Bill Haneman]

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