Accessibility APIs (was RE: Revert Request)

Silvia Pfeiffer wrote:
> 
> Maybe the a11y APIs need an update - since they, too, need to cope
> with the challenge of the changes that have been made to HTML. I don't
> think it's unreasonable to expect certain inconsistencies to emerge in
> those tools that will need to be fixed.

Hi Silvia,

If you believe this to be true, I encourage you to file bugs with the
various Operating Systems we have today(*), as those accessibility APIs are
linked not to browsers (and HTML) but rather the Operating Systems
themselves. (I'm not even sure how you would write this up as a bug). Given
the complexity of these APIs however, and the time it would take to
implement this type of fundamental change (including trickle through to
related hardware and software installations), I would argue that it is
reckless and harmful to proceed with this suggested Change Proposal at this
time.

Even if the APIs were changed however, how does this new spec-change address
tab focus? If hidden text could be made to be "html-rich" somehow, that
would then require including tab focus for many of those elements (<a>,
<li>, <td>, etc.) to allow them work properly - but tab-able for whom? Just
AT users? (How would that work?) Or all users? And if all users, what
happens when sighted users start tabbing to elements that are not visible on
screen? How does this benefit mobility impaired users, or users with
cognitive disabilities?
(See also: WCAG 2 - 2.4.7 Focus Visible: Any keyboard operable user
interface has a mode of operation where the keyboard focus indicator is
visible. (Level AA)-
http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-visibl
e.html)   

Ian's hasty change is poorly thought out, based on an incomplete and
confused understanding of accessibility requirements and needs, and creates
more problems than it sets out to solve. It is, frankly, a feeble attempt to
once again thumb his nose at not only the entire W3C process (which he is
openly disdainful of) but also the community of accessibility specialists at
the W3C (who he willfully and consistently dismisses with open contempt -
witness his continued use of the term "Cargo cult accessibility").

JF


(*)
Microsoft: 
UI Automation Team: Microsoft does not have a public bug-tracker, but the
team can be contacted via:
http://blogs.msdn.com/b/winuiautomation/archive/2009/05/15/meet-the-windows-
ui-automation-accessibility-team.aspx

Perhaps also here:
https://connect.microsoft.com/site/sitehome.aspx?SiteID=136

*************

Mac OS / iOS:
https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa/wa/signIn 

*************

Linux:
Open Accessibility (A11y) Workgroup (IAccessible2, AT-SPI2):
https://bugs.linuxfoundation.org/ 

ATK, AT-SPI, GAIL and GTK+:
http://java-gnome.sourceforge.net/doc/api/4.1/org/gnome/atk/package-summary.
html (?)
https://bugzilla.gnome.org/  

http://accessibility.kde.org/contact/  
https://bugs.kde.org/

Received on Friday, 27 January 2012 07:50:38 UTC