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
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf
> Of Sailesh Panchang
> Sent: Thursday, October 15, 2015 9:35 AM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] browsers and screen reader testing
>
> Hello Steve,
> Is the description of the experience in all cells whether marked Failed /
> Works / Works fine not sufficient or clear enough?
> Note: my focus is on the screen reader - browser combo experience.
> For instance, I have not commented on whether the placeholder text is
> available visually or has sufficient contrast for non-AT users.
>
> Thanks,
> Sailesh Panchang
>
>
> On 10/15/15, Steve Faulkner < <EMAIL REMOVED> > wrote:
>> http://www.html5accessibility.com/ documents current (June 2015)
>> browser accessibility implementation support for many "new" HTML5
>> features
>>
>> --
>>
>> Regards
>>
>> SteveF
>> Current Standards Work @W3C
>> <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w
>> 3c/>
>>
>> On 15 October 2015 at 07:04, Steve Faulkner < <EMAIL REMOVED> >
>> wrote:
>>
>>> Hi Sailesh, thanks for sharing.
>>>
>>> Suggest it would be useful to note where the tests are 'fails' due to
>>> browsers not implementing a particular feature, as these are not 'fails'
>>> are they?
>>>
>>> --
>>>
>>> Regards
>>>
>>> SteveF
>>> Current Standards Work @W3C
>>> <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-
>>> w3c/>
>>>
>>> On 15 October 2015 at 02:42, Sailesh Panchang
>>> < <EMAIL REMOVED> >
>>> wrote:
>>>
>>>> Hello Jennifer,
>>>> Thanks for your post.
>>>> I have also been experimenting with HTML5 form types over the past
>>>> few days. Here is a result of my testing. It only covers a handful
>>>> of
>>>> HTML5 elements and attributes at present.
>>>>
>>>> The table is quite packed really with my notes. There is a link to a
>>>> test page too.
>>>> Warning for non screen reader users: it might help to collapse the
>>>> columns for a couple of browsers in the data table so the content is
>>>> more easily readable.
>>>>
>>>> Please let me know if you observe something different in the screen
>>>> reader behavior.
>>>> Here is the link: www.mindoversight.com/demo/Html5ElementTable.php
>>>>
>>>> Thanks,
>>>> Sailesh Panchang
>>>>
>>>>
>>>> On 10/13/15, Jordan Wilson < <EMAIL REMOVED> > wrote:
>>>> > This is incredibly helpful, thanks for posting!
>>>> > >>>> > From: WebAIM-Forum < <EMAIL REMOVED> > on
>>>> > behalf of Jennifer Sutton < <EMAIL REMOVED> >
>>>> > Sent: Monday, October 12, 2015 1:50 PM
>>>> > To: WebAIM Discussion List
>>>> > Subject: [WebAIM] browsers and screen reader testing
>>>> >
>>>> > Greetings, WebAIM (and those who aren't on the list and being
>>>> > bcc-ed):
>>>> >
>>>> > I thought some of you might be interested in these two references
>>>> > related to browsers and screen reader testing. I know that a lot
>>>> > of us do a lot of testing and develop our own matrices and the
>>>> > like, but it would sure be nice if a one-stop resource could be
>>>> > kept up-to-date on Git, especially for those who aren't all that
>>>> > experienced with screen readers, so may not necessarily know how
>>>> > to test correctly, using the most relevant/best combos.
>>>> >
>>>> > I am sharing these resources in an effort to foster
>>>> > cooperation/collaboration in our community, such as via a Git
>>>> > resource, if Steve is willing.
>>>> >
>>>> > Yes, ideas are a dime a dozen, but it often does seem to me as if
>>>> > there's a lot of repeated effort. And this doesn't seem to me as
>>>> > if it would/should be a "special" "value add" for for--profits.
>>>> > This should all be pretty factual.
>>>> >
>>>> > Sorry, since I'm not currently fully employed, I don't have the
>>>> > band width to take on another volunteer effort. I will continue to
>>>> > do what I can, though.
>>>> >
>>>> > My two cents for the day.
>>>> >
>>>> > Thanks, as always, to Steve and TPG for so freely sharing their
>>>> > efforts.
>>>> >
>>>> > Best,
>>>> > Jennifer
>>>> >
>>>> > Rough Guide: browsers, operating systems and screen reader support
>>>> > –
>>>> Updated
>>>> > Rough Guide: browsers, operating systems and screen reader support
>>>> > – Updated
>>>> >
>>>> https://www.paciellogroup.com/blog/2014/10/rough-guide-browsers-oper
>>>> ating-systems-and-screen-reader-support-updated/
>>>> >
>>>> >
>>>> > and
>>>> >
>>>> > Aural UI of HTML Elements:
>>>> > http://thepaciellogroup.github.io/AT-browser-tests/
>>>> > >>>> > >>>> > archives at http://webaim.org/discussion/archives
>>>> > >>>> > >>>> > >>>> > archives at http://webaim.org/discussion/archives
>>>> > >>>> >
>>>> >>>> >>>> archives at http://webaim.org/discussion/archives
>>>> >>>>
>>>
>>>
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
> > > http://webaim.org/discussion/archives
> > > > > >