Thread Subject: Re: Starting discussions on the Accessibility APIproposal

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: Peter Korn
Date: Thu, Dec 14 2006 12:45 PM

Hi Loretta,

> 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?
>

It has to do with categories or classes of objects. There is a distinct
class of objects that presents a GUI for one of a range of values
(sliders, scroll bars, progress bars, etc.) - hence the Accessible Value
interface that provided when needed (menu items don't do this, neither
does static text, etc.).

Name & description, on the other hand, are applicable to everything.
Everything might have a name, everything might have a description.
Things of the same class will differ on whether or not they have one or
both. In many instances, it would be appropriate for a container
element to have a name.


The way we implemented this in object oriented environments like Java
and UNIX GNOME is with object interfaces. An AT receives a reference to
an object (an object representing the user interface element
accessibility information), and makes both direct method calls on it
("What is your accessible name?") as well as interface queries on it
("are you a think that takes on a range of values?", "are you a think
that presents editable text?").

You might suggest that we treat everything in the same way - that all
information is potentially "provided when needed" (or "provided when
appropriate to the object"). But I believe there is a significant
distinction. If the objects presents a value (implements the Accessible
Value interface) then it *must* be able to answer the questions "what is
your minimum value?", "what is your maximum value?", "what is your
current value?", and must further accept the directive "set your value
to X". So there are collections of questions/methods that belong
together. If the thing is a "value thing", then you know it will
provide all of the value functionality. If the thing is an editable
text then, you know it will provide all of the editable text
functionality.


Does that help explain why we did it that way in the proposal?


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.
> 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