RE: Exclusion of Visual Readers with Low Vision form WCAG 2.0 and the 508 Revise

[Steve wrote] the WAI-ARIA 1.0 User Agent Implementation Guide [1] does just
this, in particular refer to Supporting Keyboard Navigation [2]



I don’t think is enough.  I’m thinking of situations like toolbars where the
whole toolbar has a tabIndex=0 and the ARIA spec recommends
aria-activedescendant and keyboard handling to move among toolbar items.
This is cited as an acceptable way rather than applying to tabIndex=0 to the
currently focused item.  The way I read the current requirements is that the
user agent would only need to provide focus indication and coordinates for
the entire toolbar and not the actual active-descendant because it doesn’t
have a level of keyboard access that the user agent can detect except for
the presence of the aria-activedescendant attribute!  This is what I mean by
a disconnect between these new techniques and what users agents must do.



In a similarly frustrating fashion the accessible JQuery UI work that I’ve
seen places a checkbox off-screen to represent a toggle button.  Screen
magnifiers are not able to track correctly as the coordinates are
off-screen.  Yet there is a faux visual rectangle on the item but that
doesn’t help magnifiers.   The non-normative documents in WCAG 2 really need
to call out the danger of such techniques and indicate them as known
failures.



I log a comment on UAAG to address aria-activedescendant.



Jonathan



[Jonathan’s original statement for reference]

User agents
> need to render that that element as the active element with programmatic
> focus and exposure of location coordinates of that element to assist
> proper tracking for screen magnification software.  In my opinion this
> needs to be mapped into MSAA for Windows and whatever other
accessibility
> APIs exist for the given platform.  Perhaps this is something that can
> be addressed in UAAG 2.0.