Thread Subject: Starting discussions on the Accessibility APIproposal

Return to this mailing list's archives

From: Peter Korn
Date: Wed, Dec 13 2006 1:00 PM
Subject: Starting discussions on the Accessibility APIproposal

Fulfilling an action item from two weeks ago, Andrew Kirkpatrick and I
have put together a proposal that specifies the minimum user interface
element information that applications should provide to assistive
technologies. Essentially it specifies the minimum contents of an
"accessibility API" - the programming interface for conveying
accessibility information from applications to assistive technologies.
As per the action item from our subcommittee meeting two weeks ago, this
was explicitly reviewed by Luke Kowalski (and while I was at it, also
reviewed by two of my colleagues at Sun, Earl Johnson & Michele Budris).

This proposal can be found at:
http://teitac.org/wiki/Web_and_Software:Accessibility_API_Proposal


I'd like to start a discussion on this list about the proposal.
Specifically, there are 3 questions that I've posed at the end of the
proposal, which is perhaps a good starting point for some discussion.
See them at:
http://teitac.org/wiki/Web_and_Software:Accessibility_API_Proposal#Questions_about_this_document:
They are:

1. This document doesn't contain a set of minimum roles. This is
intentional, as that would imply a minimum set of user interface element
types. However, does that gap present AT-IT interopreability issues?
2. This document doesn't contain a set of minimum state definitions.
This is intentional, as that would imply a minimum set of user interface
element behaviors. However, does that gap present AT-IT interopreability
issues?
3. There is no specification for text attributes (e.g. CSS). This is
intentional, as that would imply a minimum set of text stylings.
However, does that gap present AT-IT interopreability issues?


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

From: Travis Roth
Date: Thu, Dec 14 2006 9:35 AM
Subject: Re: Starting discussions on the AccessibilityAPIproposal

Hi Peter,

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?

Thanks.

--
Travis Roth
Production Manager
TecAccess, LLC
(804) 749-8646 (office)
(402) 466-0907 (direct)
= EMAIL ADDRESS REMOVED =
www.TecAccess.net
Experts in Section 508 Compliance & Accessibility

NOTICE: This communication may contain privileged or other confidential
information. If you are not the intended recipient or believe that you may
have received this communication in error, please reply to the sender
indicating that fact and delete the copy you received. Thank you.

From: Peter Korn
Date: Thu, Dec 14 2006 11:05 AM
Subject: Re: Starting discussions on the Accessibility APIproposal

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.

From: Loretta Guarino Reid
Date: Thu, Dec 14 2006 11:20 AM
Subject: Re: Starting discussions on the AccessibilityAPIproposal

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

From: Victor Tsaran
Date: Thu, Dec 14 2006 11:35 AM
Subject: Re: Starting discussions on the AccessibilityAPIproposal

I must fully agree with Peter here. The API should be able to
ask these questions and it should be the responsibility of the
software app to either answer or ignore the questions. Even if
the name or description duplicate the information, provided on
the screen elsewhere, the decision-making on how to handle the
duplication should be left to AT.
Just my two cents,
Victor

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

From: Travis Roth
Date: Thu, Dec 14 2006 12:24 PM
Subject: Re: Starting discussions on the AccessibilityAPIproposal

Hi Peter,

Thanks. In terms of the assistive technology being able to make these
accessibility calls such as getAccessibleName() and getting a response, or
at least not a crash, I agree.
I do wonder if this is bordering on implementation but I'm not sure.

Along the lines of the object responding to the question, shouldn't the
other essentials also be obliated to answer e.g., "what is your Role and
children?" I realize most everything will have a role, but many UI elements
may not have children, the same as they may not have a description.

--
Travis Roth
Production Manager
TecAccess, LLC
(804) 749-8646 (office)
(402) 466-0907 (direct)
= EMAIL ADDRESS REMOVED =
www.TecAccess.net
Experts in Section 508 Compliance & Accessibility

NOTICE: This communication may contain privileged or other confidential
information. If you are not the intended recipient or believe that you may
have
received this communication in error, please reply to the sender indicating
that fact and delete the copy you received. Thank you.

From: Peter Korn
Date: Thu, Dec 14 2006 12:45 PM
Subject: Re: Starting discussions on the Accessibility APIproposal

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

From: Hoffman, Allen
Date: Thu, Dec 14 2006 12:50 PM
Subject: Re: Starting discussions on the AccessibilityAPIproposal

All:
See
http://msdn.microsoft.com/robotics/

Where do we feel robotic IT may fit in the 508 universe! I think this
may start becoming more and more something to consider.

Allen hoffman
DHS Office on Accessible systems & Technology

From: Peter Korn
Date: Thu, Dec 14 2006 1:25 PM
Subject: Re: Starting discussions on the Accessibility APIproposal

Hi Travis,
> Thanks. In terms of the assistive technology being able to make these
> accessibility calls such as getAccessibleName() and getting a response, or
> at least not a crash, I agree.
> I do wonder if this is bordering on implementation but I'm not sure.
>
> Along the lines of the object responding to the question, shouldn't the
> other essentials also be obliated to answer e.g., "what is your Role and
> children?" I realize most everything will have a role, but many UI elements
> may not have children, the same as they may not have a description.

We should definitely go through this draft specification and make sure
the language makes clear what information must/can be provided, for each
of the "questions" that AT can ask of a user interface element. In the
case of children, I image the question is really "How many children do
you have?", with the answer being an integer greater than or equal to
0. So a user interface element that has no children, would more
precisely "have 0 children".

A challenge here is to come up with language that meets our criteria -
harmonization, AT-IT interoperability, and testability - while at the
same time not specifying the implementation. What I tried to do with
this proposal is be specific enough to be testable (one can verify by
inspection whether an accessibility API or a user interface element
provides the information described in the proposal), but general enough
to allow for a wide range of implementations.

If we were to put this proposed language (or more likely a derivative of
it) into 508, then we might further specify in the "sufficient
techniques" section that existing platform accessibility APIs like UI
Automation and the Macintosh NSAccessible and the UNIX Accessibility
framework are known sufficient techniques on their respective
platforms. I would also look to include WAI ARIA in that - but how we
do that depends on how we wind up treating Web applications - do they
fall in Web, in Software, in both, in neither? Thus, if a purchasing
agency wanted to know whether (for example) a Macintosh application met
this portion of 508, it would be sufficient for the agency to know that
the application implemented the NSAccessible interface. While it may be
difficult to test this exhaustively - to verify that every question that
can be asked of a user interface element is answered properly by *every*
user interface element in *every* possible circumstance - one can
generally verify that an application is or is not implementing the
NSAccessible interface (or the UI Automation interface or the UNIX
Accessibility framework). We have test tools that do this already for
Java and UNIX; I expect Apple and Microsoft have similar test tools.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

From: Jim Tobias
Date: Thu, Dec 14 2006 3:15 PM
Subject: Re: Starting discussions on the AccessibilityAPIproposal

I'm reading this thread with great interest. Two questions come to mind:

1. The most obvious case for applying an Accessibility API is when there is
one software product communicating with one AT product, but that's not the
only case, or maybe even the most typical case. Is it correct to assume
that any specifications here would need to be applied to all the software in
the stack, so that the accessibility information is continuously exposed and
passed along as needed?

2. If the mainstream product exposes this necessary information, what are
the implications for the AT at the "last mile"? Are you anticipating
writing specifications for how the AT handles this information? This raises
the issue of whether AT is E&IT and therefore within the purview of TEITAC.

Thanks.

***********
Jim Tobias
Inclusive Technologies
= EMAIL ADDRESS REMOVED =
+1.732.441.0831 v/tty
skype jimtobias
www.inclusive.com


> -----Original Message-----
> From: Peter Korn [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Thursday, December 14, 2006 3:22 PM
> To: = EMAIL ADDRESS REMOVED = ; TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Starting discussions on the
> Accessibility APIproposal
>
> Hi Travis,
> > Thanks. In terms of the assistive technology being able to
> make these
> > accessibility calls such as getAccessibleName() and getting a
> > response, or at least not a crash, I agree.
> > I do wonder if this is bordering on implementation but I'm not sure.
> >
> > Along the lines of the object responding to the question, shouldn't
> > the other essentials also be obliated to answer e.g., "what is your
> > Role and children?" I realize most everything will have a role, but
> > many UI elements may not have children, the same as they
> may not have a description.
>
> We should definitely go through this draft specification and
> make sure the language makes clear what information must/can
> be provided, for each of the "questions" that AT can ask of a
> user interface element. In the case of children, I image the
> question is really "How many children do you have?", with the
> answer being an integer greater than or equal to 0. So a
> user interface element that has no children, would more
> precisely "have 0 children".
>
> A challenge here is to come up with language that meets our
> criteria - harmonization, AT-IT interoperability, and
> testability - while at the same time not specifying the
> implementation. What I tried to do with this proposal is be
> specific enough to be testable (one can verify by inspection
> whether an accessibility API or a user interface element
> provides the information described in the proposal), but
> general enough to allow for a wide range of implementations.
>
> If we were to put this proposed language (or more likely a
> derivative of
> it) into 508, then we might further specify in the
> "sufficient techniques" section that existing platform
> accessibility APIs like UI Automation and the Macintosh
> NSAccessible and the UNIX Accessibility framework are known
> sufficient techniques on their respective platforms. I would
> also look to include WAI ARIA in that - but how we do that
> depends on how we wind up treating Web applications - do they
> fall in Web, in Software, in both, in neither? Thus, if a
> purchasing agency wanted to know whether (for example) a
> Macintosh application met this portion of 508, it would be
> sufficient for the agency to know that the application
> implemented the NSAccessible interface. While it may be
> difficult to test this exhaustively - to verify that every
> question that can be asked of a user interface element is
> answered properly by *every* user interface element in
> *every* possible circumstance - one can generally verify that
> an application is or is not implementing the NSAccessible
> interface (or the UI Automation interface or the UNIX
> Accessibility framework). We have test tools that do this
> already for Java and UNIX; I expect Apple and Microsoft have
> similar test tools.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>

From: Peter Korn
Date: Thu, Dec 14 2006 7:55 PM
Subject: Re: Starting discussions on the Accessibility APIproposal

Hi Jim,

We've been discussing some of these "platform on platform" issues in the
Web & Software con-calls. Fundamentally things that are their own
platforms or "platform players" - like Flash player or the Java runtime
or frankly a Web browser - need to have one foot on both worlds. The
Web browser must understand the rich accessibility API of WAI ARIA when
exposed by dynamic web applications; and it must provide that
information in a way that assistive technologies can understand it.

Today Firefox 1.5/2.0 does this to a significant extent, implementing
support for the WAI ARIA draft and exposing it to WindowEyes and JAWS
which have done special and significant work to support this capability
in Firefox 1.5 and now 2.0. That work is a significant advance in web
application accessibility. It does not quite meet the ideal we are
sketching out - of the browser then taking the WAI ARIA information and
exposing it via a standard accessibility API to Windows AT products; but
Firefox is moving in that direction (and we are specifically working
with IBM and the Mozilla foundation to implement exactly that approach
in UNIX).


One thing that we should NOT loose track of is that this accessibility
API proposal is in the context of the existing 508 language of
equivalent facilitation. Just because we say that the "API route is the
way to go" in no way bars an application accomplishes the same goal
working with AT some other way. So back to the WAI ARIA example with
Firefox - because Firefox 1.5 and 2.0 expose dynamic web application
information that is supported by WindowEyes and JAWS, they have
delivered equivalent facilitation - at least for the vast majority of
blind users on Windows. I believe that should be perfectly acceptable
under an updated 508 that otherwise embraces the accessibility API
approach.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> I'm reading this thread with great interest. Two questions come to mind:
>
> 1. The most obvious case for applying an Accessibility API is when there is
> one software product communicating with one AT product, but that's not the
> only case, or maybe even the most typical case. Is it correct to assume
> that any specifications here would need to be applied to all the software in
> the stack, so that the accessibility information is continuously exposed and
> passed along as needed?
>
> 2. If the mainstream product exposes this necessary information, what are
> the implications for the AT at the "last mile"? Are you anticipating
> writing specifications for how the AT handles this information? This raises
> the issue of whether AT is E&IT and therefore within the purview of TEITAC.
>
> Thanks.
>
> ***********
> Jim Tobias
> Inclusive Technologies
> = EMAIL ADDRESS REMOVED =
> +1.732.441.0831 v/tty
> skype jimtobias
> www.inclusive.com
>
>
>
>> -----Original Message-----
>> From: Peter Korn [mailto: = EMAIL ADDRESS REMOVED = ]
>> Sent: Thursday, December 14, 2006 3:22 PM
>> To: = EMAIL ADDRESS REMOVED = ; TEITAC Web/Software Subcommittee
>> Subject: Re: [teitac-websoftware] Starting discussions on the
>> Accessibility APIproposal
>>
>> Hi Travis,
>>
>>> Thanks. In terms of the assistive technology being able to
>>>
>> make these
>>
>>> accessibility calls such as getAccessibleName() and getting a
>>> response, or at least not a crash, I agree.
>>> I do wonder if this is bordering on implementation but I'm not sure.
>>>
>>> Along the lines of the object responding to the question, shouldn't
>>> the other essentials also be obliated to answer e.g., "what is your
>>> Role and children?" I realize most everything will have a role, but
>>> many UI elements may not have children, the same as they
>>>
>> may not have a description.
>>
>> We should definitely go through this draft specification and
>> make sure the language makes clear what information must/can
>> be provided, for each of the "questions" that AT can ask of a
>> user interface element. In the case of children, I image the
>> question is really "How many children do you have?", with the
>> answer being an integer greater than or equal to 0. So a
>> user interface element that has no children, would more
>> precisely "have 0 children".
>>
>> A challenge here is to come up with language that meets our
>> criteria - harmonization, AT-IT interoperability, and
>> testability - while at the same time not specifying the
>> implementation. What I tried to do with this proposal is be
>> specific enough to be testable (one can verify by inspection
>> whether an accessibility API or a user interface element
>> provides the information described in the proposal), but
>> general enough to allow for a wide range of implementations.
>>
>> If we were to put this proposed language (or more likely a
>> derivative of
>> it) into 508, then we might further specify in the
>> "sufficient techniques" section that existing platform
>> accessibility APIs like UI Automation and the Macintosh
>> NSAccessible and the UNIX Accessibility framework are known
>> sufficient techniques on their respective platforms. I would
>> also look to include WAI ARIA in that - but how we do that
>> depends on how we wind up treating Web applications - do they
>> fall in Web, in Software, in both, in neither? Thus, if a
>> purchasing agency wanted to know whether (for example) a
>> Macintosh application met this portion of 508, it would be
>> sufficient for the agency to know that the application
>> implemented the NSAccessible interface. While it may be
>> difficult to test this exhaustively - to verify that every
>> question that can be asked of a user interface element is
>> answered properly by *every* user interface element in
>> *every* possible circumstance - one can generally verify that
>> an application is or is not implementing the NSAccessible
>> interface (or the UI Automation interface or the UNIX
>> Accessibility framework). We have test tools that do this
>> already for Java and UNIX; I expect Apple and Microsoft have
>> similar test tools.
>>
>>
>> Regards,
>>
>> Peter Korn
>> Accessibility Architect,
>> Sun Microsystems, Inc.
>>