WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Please test our expanding content

for

From: Paul J. Adam
Date: Apr 3, 2015 11:16AM

Lots of trial and error with ARIA widgets and testing with many different screen readers :) Have to create lots of demos and test them out to find out if they really work with the screen readers, keyboard users.

I've read other a11y folks recommend the state be placed on the focusable elements but I've seen that mistake many times with lots of nesting of parent/child elements to construct a widget.

The HTML5 nu validator will catch those errors as well :)

The spec can only be trusted up to the point before you need to actually test your assumptions with the various screen readers. Mobile makes it even harder!

aria-controls doesn't even really do anything at the moment but you are supposed to use it also.

I'm just happy that aria-expanded=true|false finally works 'correctly' on VoiceOver for iOS 8! But not on role=link sadly.

Paul J. Adam
Accessibility Evangelist
www.deque.com <http://www.deque.com/>;
> On Apr 3, 2015, at 12:24 PM, _mallory < <EMAIL REMOVED> > wrote:
>
> On Fri, Apr 03, 2015 at 11:43:06AM -0500, Paul J. Adam wrote:
>>
>> Here's a working example, http://pauljadam.com/demos/aria-expanded.html <http://pauljadam.com/demos/aria-expanded.html>;.
>
> How does a developer know when the aria-expanded goes on the expander
> and when it goes on the thingie getting expanded?
>
> I thought you'd put aria-expanded=true/false on the hidden/shown p
> there, not the controlling link. The link doesn't itself expand
> or contract.
>
> I know the specs say either way, but that's 100% unhelpful for
> stupids like me trying to figure out which of the 2 ways actually
> makes sense.
>
> thanks,
> _mallory
> > > >