WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: browsers and screen reader testing

for

From: Sailesh Panchang
Date: Oct 15, 2015 8:58AM

Hi Jonathan,
Refer: www.mindoversight.com/demo/Html5ElementTable.php
I believe the focus of the test is "practical accessibility using
different browser and screen reader combos.
Let me give you another example from the table: VO with Safari On OSX
only announces the value in a type=range control ... but on iOS it
reads the associated number (125, 130, etc.) as well .
On Windows, the screen readers only read the range value: 125, 130, etc.
No I have not commented on what the range control actually displays
or works with no AT in use. I kept it out of scope for my testing.
That's why I chose not to give a single word descriptor in every cell
like Pass / Fail but included an explanation. Notice the required
attribute works in forms mode but the placeholder when out of forms
mode in IE and JAWS.
I believe the title of the page and the table conveyed the objective.
Maybe I will clarify the objective of the test with a statement or
two.
Thanks,
Sailesh


On 10/15/15, Jonathan Avila < <EMAIL REMOVED> > wrote:
>> Is the description of the experience in all cells whether marked Failed /
>> Works / Works fine not sufficient or clear enough?
>
> Sailesh, I would agree with Steve that by marking it as a failure it is
> implied that it is a screen reader failure or an accessibility failure when
> instead it's that the browser did not implement the feature for all users.
> Personally I would find a comparison between the feature as implemented for
> all users compared to the accessibility experience most helpful.
>
> All, I appreciate everyone's efforts creating these types of matrices -- I
> create them myself. One thing that I see others do (not you specifically)
> is make general statements without documenting that nuanced ways things are
> exposed. That is, I've found with screen readers that things may be
> announced different with tab than with arrows in browser/virtual cursor
> mode, etc. So it's very important to document the method of navigation.
> Another example is how a technique is performed. For example, someone might
> conclude that aria-live is not work but there are multiple ways to implement
> dynamic content changes, e.g. display, visibility, node additional removal,
> text node removal additions, etc. and I've found that the varying methods
> may have different results. Thus, it is very important for those of us
> including myself to be very clear on these factors. So this is just
> something for everyone to keep in mind.
>
> Jonathan
>
> --
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> <EMAIL REMOVED>
> Phone 703.637.8957
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>