E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 4 (In chronological order)

From: Bryan Garaventa
Date: Fri, Feb 24 2017 12:20PM
Subject: An Interactive ARIA Widget Checklist: For Screen Reader Testing
No previous message | Next message →

Hello,
The following blog post was just published which should aid in more equal screen reader testing across various screen reader / browser combinations for the most commonly used interactive ARIA widget constructs.

https://www.ssbbartgroup.com/blog/aria-widget-checklist-screen-reader-testing/

All the best,
Bryan


Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
= EMAIL ADDRESS REMOVED =
415.624.2709 (o)
www.SSBBartGroup.com

From: Lucy Greco
Date: Fri, Feb 24 2017 1:00PM
Subject: Re: An Interactive ARIA Widget Checklist: For Screen Reader Testing
← Previous message | Next message →

brian this is a vary helpful tool. any chance you can expand on it as to
how voice input should behave or am i asking to much smile

Lucia Greco
Web Accessibility Evangelist
IST - Architecture, Platforms, and Integration
University of California, Berkeley
(510) 289-6008 skype: lucia1-greco
http://webaccess.berkeley.edu
Follow me on twitter @accessaces


On Fri, Feb 24, 2017 at 11:20 AM, Bryan Garaventa <
= EMAIL ADDRESS REMOVED = > wrote:

> Hello,
> The following blog post was just published which should aid in more equal
> screen reader testing across various screen reader / browser combinations
> for the most commonly used interactive ARIA widget constructs.
>
> https://www.ssbbartgroup.com/blog/aria-widget-checklist-
> screen-reader-testing/
>
> All the best,
> Bryan
>
>
> Bryan Garaventa
> Accessibility Fellow
> SSB BART Group, Inc.
> = EMAIL ADDRESS REMOVED =
> 415.624.2709 (o)
> www.SSBBartGroup.com
>
>
> > > > >

From: Bryan Garaventa
Date: Fri, Feb 24 2017 2:12PM
Subject: Re: An Interactive ARIA Widget Checklist: For ScreenReader Testing
← Previous message | Next message →

Hi,
Actually it does do that in a general sense stating what should be conveyed or announced within the expected behaviors notation, but this is deliberately vague because it's meant to apply across both desktop and mobile. Obviously the keyboard commands are limited to desktop-type platforms, but what is conveyed and announced may vary also depending on the platform and assistive technology being used at the time.

Basically this is meant to shine a light on where specific screen readers can't even do this much and are causing such controls to be deemed inaccessible by users as a result. Since all of these widgets strictly follow the ARIA 1.0 spec guidance for these widget types there is no excuse for this besides a lack of exposure to how these widgets are properly coded in a structured manner like this.

So it's important for people to file bugs where support issues are found to exist in these cases, and to do so all of the time.

This will cause positive changes to happen.



Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
= EMAIL ADDRESS REMOVED =
415.624.2709 (o)
www.SSBBartGroup.com

From: Birkir R. Gunnarsson
Date: Sat, Feb 25 2017 3:15PM
Subject: Re: An Interactive ARIA Widget Checklist: For Screen Reader Testing
← Previous message | No next message

Great job!

I will sit down and review these with some of the most common screen
reader/browser combinations.
One thought, you may want to specify that the keyboard control
(elements being focusable and keyboard navigation between elements)
must be coded by the author, either using JavaScript or by applying
the role on a native HTML control with a similar functionality.
Or you may expand the note to say that any interaction (keyboard
focusability and navigation, change of ARIA roles and states etc.)
must be implemented by the author.

A quick read of this by someone without experience may lead that
person to believe that the keyboard behavior comes for free with the
right use of ARIA roles and attributes.


On 2/24/17, Bryan Garaventa < = EMAIL ADDRESS REMOVED = > wrote:
> Hi,
> Actually it does do that in a general sense stating what should be conveyed
> or announced within the expected behaviors notation, but this is
> deliberately vague because it's meant to apply across both desktop and
> mobile. Obviously the keyboard commands are limited to desktop-type
> platforms, but what is conveyed and announced may vary also depending on the
> platform and assistive technology being used at the time.
>
> Basically this is meant to shine a light on where specific screen readers
> can't even do this much and are causing such controls to be deemed
> inaccessible by users as a result. Since all of these widgets strictly
> follow the ARIA 1.0 spec guidance for these widget types there is no excuse
> for this besides a lack of exposure to how these widgets are properly coded
> in a structured manner like this.
>
> So it's important for people to file bugs where support issues are found to
> exist in these cases, and to do so all of the time.
>
> This will cause positive changes to happen.
>
>
>
> Bryan Garaventa
> Accessibility Fellow
> SSB BART Group, Inc.
> = EMAIL ADDRESS REMOVED =
> 415.624.2709 (o)
> www.SSBBartGroup.com
>
>
>