WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Browser version advice in accessibility statement

for

From: Kevin Chao
Date: Nov 6, 2011 6:09PM

Hi Birkir,

I shared your concerned/inability to switch to NVDA and Braille support with:
NVDA screen reader development < <EMAIL REMOVED> >
and I've already received two very thought out, detailed, and
comprehensive responses. One of the many things i absolutely enjoy
about NVAccess/NVDA. The thing i enjoy even more than this is when an
issue ticket is filed with sufficient info, it's addressed very
quickly, and I've seen several issues I've filed closed within 3
hours.

James Teh
Vice President, Developer

First, as always, significant work requires funding. I'm doing what I
can to work on this regardless, but we haven't really found anyone
willing to fund extensive work on braille. If anyone has any ideas,
please let us know.

Please have the user provide more details. Only one example was given,
which is hardly enough to justify "not sufficient".

What is meant by "mouse simulation"? If a cursor routing key is
pressed on an object, it will activate that object. In an editable
text field or document, it moves the cursor to that position.

As Mesar noted, if enhancements or fixes are desired, tickets should
be filed with detailed explanations (after first searching to see
whether one has already been filed, of course).

http://www.nvda-project.org/wiki/Development#IssueTracker

Mesar Hameed
I am pretty sure that the features the person is speaking of work, and
if not its a question of remapping the buttons/wheels to the
functionality that they want.

I have had to do this for some people on the arabic mailing list.

I suspect that they didnt read the remapping gestures section of the
userguide (advanced topics)

If they have a problem with a particular display they are more than
welcome to report it and of course we will all try to help.

The first step is to request for information or to read the manual,
sadly too many people have a lot of presumptions, not understanding that
the system is flexable. Of course there are things that are outstanding,
but we will only improve by people opening tickets and describing the
problem in detailed and explaining how they wish the issue to be solved.

Thanks,

Kevin

On 11/6/11, Birkir R. Gunnarsson < <EMAIL REMOVED> > wrote:
> Kevin
>
> Agreed for the most part, in fact nearly completely.
> Cool to know that Chrome is coming around when it comes to accessibility.
> I've been waiting to try it out because I knew there were significant
> issues in the past, but it seems now the time has come to try it out.
> I am a little more conservative when it comes to A.T. and NVDA specifically.
> There are two reasons for this:
> a. Non-technical users (and let's face it, they are probably a
> majority of users). I did not realize how much you need to hold their
> hand until I started working part time for a resource center, in
> charge of A.T. and training. There is a lot of people out there who
> will not download and install browsers, updates and A.T. by
> themselves. They have a fixed set up taylorred to what they want to do
> with computers, and specific training and instructions on how to get
> those things done. We have to keep them in mind to some degree, even
> as the web moves forward. We can significantly simplify their learning
> curve by doingmore work on standardizing ARIA implimentations,
> keyboard accessibility etc, by utilizing technical users first, making
> it easier for non-technical folks to make the switch.
>
>
> b. NVDA braille support is sadly still lacking significantly, which is
> the reasonI still stick with Jaws as my main screen reader. This is
> getting past the topic of this list, but I believe the OpenBraile
> project failed, and there won't be a universal API access to
> supporting braille displays in the near future on the Windows
> platform, which is a crying shame. Regardless of that, NVDA needs to
> do more when it comes to braile support. There is progress, but it's
> not sufficient. Many users in Europe, who are fortunate enough to get
> significant budgets towards purchasing A.T. hardware, rely heavily on
> braille for a lot of computer activities, for instance the mouse
> simulation keys whih NVDA does not support, at least not on the
> displays I have tested (Focus, Alva Satellite, Seika and Baum). I hope
> this can be fixed.
>
> Cheers
> -B
>
> On 11/6/11, Kevin Chao < <EMAIL REMOVED> > wrote:
>> There's no excuse or reason at all one should not be running the
>> latest web browser and assistive technology, such as screen reader.
>> There's performance, security, accessibility, usability, support, etc.
>> benefits. Vendors/industry should not be limited due to users refusing
>> to update.
>>
>> I think that HTML5 and ARIA should only be applied when needed, such
>> as rich, interactive, and dynamic sites. If a website is a fairly
>> static site and standard HTML4 markup will work, there's no need to
>> add additional complexity by adding in ARIA. However, if in the road
>> map of a company/site has plans on adding more rich, interactive, and
>> dynamic components; it's best to build in the HTML5 and ARIA support
>> during the R&D stage.
>>
>> When it comes to web browser and assistive technology support, the web
>> is moving very quickly, and in order for companies/websites to keep
>> up; the minimum requirement and support must be very strict. It should
>> be forced to current and previous version, nothing more.
>>
>> Firefox+NVDA, specifically 10 Nightly and 2011.3 Snapshot has the most
>> fastest, solid, accurate, and rich support for the web, specifically
>> HTML5 and ARIA.
>> NVDA works very well with Chrome 17 Canary and Google is actively
>> working on fixing a lot of accessibility support in many areas,
>> including HTML5 and ARIA.
>>
>> Chrome+ChromeVox on Windows or Mac has very good support for the web
>> (rich, dynamic, and interactive), but ARIA support is a work in
>> progress.
>>
>> Internet Explorer 9/8 does not have proper, robust, and rich
>> accessibility API's for ARIA and HTML5. Any AT/screen reader who
>> claims support for it is hacking support in, which results in poor
>> performance, instability, and buggy/inaccurate results.
>>
>> iOS 5, VoiceOver, and Safari made a lot of great strides, especially
>> over iOS 4.3.X in improving HTML5 and ARIA accessibility support.
>>
>> OS X Lion, Safari, and Voiceover just added ARIA support, it's quite
>> weak, and has a ways to go still. However, its support for HTML5 and
>> ARIA is far better than Window-Eyes, who has very weak web support,
>> and no HTML5 or ARIA.
>>
>> I'm not sure how well SuperNova and System Access HTML5 and ARIA support
>> is.
>>
>> Opera web browser should not even been considered at all or mentioned
>> until it's fully accessible with various assistive technologies.
>>
>> As a user myself, I don't think it's unreasonable at all to ask the
>> end-user of a website to upgrade to the latest web browser and AT to
>> fully utalize, leverage, and benefit from the Web 2.0 features of the
>> website. This should not be provided in a hidden link, but a visible
>> link, which when viewed provides the best combination, which on
>> Windows is Firefox+NVDA. NVDA, which is free and open source has the
>> best support, which results in the cost factor/excuse being thrown out
>> the window.
>>
>> Most of the paid commercial screen readers are ones that I don't use
>> as their bloated, buggy, slow, and don't have great support for the
>> web, such as HTML5 and ARIA.
>>
>> Kevin
>>
>> On 11/6/11, Aaron Leventhal < <EMAIL REMOVED> > wrote:
>>> We definitely all need the compatibility list!
>>>
>>> Also, as far as inconsistent implementations of ARIA and how it affects
>>> older users ... If ARIA is implemented well the user should not have any
>>> trouble, because on almost l cases the accessibility behavior should be
>>> what
>>> they are already accustomed to. The inconsistency really points to the
>>> need
>>> for the ARIA developer portal where proper ARIA techniques are discussed
>>> and
>>> documented. We need aria testing tools, and we need a community that is
>>> more
>>> involved. We need to Identify and document the techniques and issues or
>>> inconsistencies in key implementations, and get after developers to fix
>>> their bugs.
>>>
>>> I believe this is all possible.
>>>
>>> Aaron
>>>