[Accessibility-atspi] Re: [Accessibility] Two diffferent ATK
implementations for HTML document structures
Peter Korn
Peter.Korn at Sun.COM
Thu Mar 2 09:38:16 PST 2006
Hi Bill, guys,
> Fine by me, but I'd like to hear from others in the group before adding
> a relation type. (Actually two types, as you point out this would be a
> reciprocal DESCRIPTION_FOR/DESCRIBED_BY pair).
>
This seems like a valid and valuable relation set to add.
Peter
> Bill
>
> On Thu, 2006-03-02 at 05:13, Aaron M Leventhal wrote:
>
>>> 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
>>>
>>
>>
>> ______________________________________________________________________
>> _______________________________________________
>> Accessibility-atspi mailing list
>> Accessibility-atspi at lists.freestandards.org
>> http://lists.freestandards.org/cgi-bin/mailman/listinfo/accessibility-atspi
>>
>
> _______________________________________________
> Accessibility mailing list
> Accessibility at lists.freestandards.org
> http://lists.freestandards.org/cgi-bin/mailman/listinfo/accessibility
>
More information about the Accessibility
mailing list