Thread Subject: Re: Starting discussions on the AccessibilityAPIproposal

Note

This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.

From: Loretta Guarino Reid
Date: Thu, Dec 14 2006 11:20 AM

Hi, Peter,

How did you decide that Name and Description should be supported, even
if the the object doesn;t have a name or description, but other
information is only provided when needed (e.g. additional information
for editable text objects, additional information for objects within a
table). Couldn't name and description have been handled similarly?

Loretta

On 12/14/06, Peter Korn < = EMAIL ADDRESS REMOVED = > wrote:
> Hi Travis,
>
> > Would you explain further the notes on these two items in the "Minimum
> > 'static' information for all user interface elements shown on the screen"
> > section?
> >
> > "5. Name of the object (note: not all objects necessarily will have a name,
> > especially if that duplicates text provided elsewhere in the API; but all
> > objects must be able to answer the question "what is your name?")
> > 6. Description of the object (note: not all objects necessarily will have a
> > description, especially if that duplicates text provided elsewhere in the
> > API; but all objects must be able to answer the question "what is your
> > description?") "
> >
> > If not all objects will have a name or description, but need to answer the
> > question, what should the answer be?
>
> What I am trying to say (and perhaps am saying poorly) is that every
> user interface element should understand the questions "what is your
> name?" and "what is your description?". This is a statement about the
> completeness of the API - the programming interface. However, it is not
> the case that every user interface element *must* have a description.
> Many times the name will be sufficient. For example, the "Save" menu
> item in the "File" menu is pretty well understood - no description
> should need to be provided. But other menu items, and certainly other
> user interface elements, may need to have a description to be
> understood. An excellent rule of thumb is if an element has a tooltip,
> it should probably have a description (and perhaps the tooltip text
> should be the description - that is what we do automatically in Java and
> UNIX).
>
> Similarly, there are user interface elements that may be exposed via the
> accessibility API that need not even have a name. Something like a
> "container" object - it may not be visible on the screen and it
> certainly has no text in it (though some of the things it contains may
> have text and will be their own user interface element). Thus those
> don't need to have a name either. Their answer would be "I have no
> name" (which would typically be implemented with a NULL return value to
> the method call).
>
> BUT, being able to be asked the question is a basic part of the API.
> All user interface elements should be able to be asked that question,
> even if they then say "sorry, I don't have a name". This greatly
> simplifies the programming model - you create an accessible menu user
> interface element that has "getAccessibleName()" and
> "getAccessibleDescription()" methods on it. Then all menus are able to
> answer the question. Then whenever a programmer puts menus into their
> application, they simply fill in the "name" and/or "description" fields
> of the object, and the already-written object code takes care of the
> task of conveying this to assistive technologies. If further the menu
> user interface element code knows to look for tooltip text if the
> programmer provided that but failed to provide description text, then
> the AT will automatically get useful and appropriate information when it
> asks for the description. Likewise, if the menu user interface element
> code knows to look for the menu text if no name was provided, the AT
> will automatically get a useful name. This is exactly how we have
> implemented menu user interface elements in Java/Swing and in UNIX GTK+
> (and StarOffice UNO and Mozilla XUL). However, that is an
> implementation detail in how we have done it, and not something I think
> 508 should say anything about.
>
>
> I hope my lengthy answer has satisfied your question...
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University