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

Hi Jonathon,
as implemented in browsers aria-activedescendent provides the location
information via the accessibility APIs that is picked up by AT

I tried example:
http://oaa-accessibility.org/example/29/

tested it with inspect32, the location information for the individual radio
buttons was exposed.
tried it with zoom text and the focus ring worked correctly.


regards
stevef


On 19 October 2011 14:15, Jonathan Avila <jon.avila@ssbbartgroup.com> wrote:

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


-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html