[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