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

Thu Mar 2 02:05:24 PST 2006

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).

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