[nfbcs] My Opinion and Experiences with Accessibility

Nicole Torcolini ntorcolini at wavecable.com
Wed Mar 5 02:37:01 UTC 2014 

Chrome works better with NVDA or ChromeVox than with JAWS, but that is
Freedom Scientific's fault. Although this is not always the case, usually,
if something works with NVDA but not with JAWS, then it is because Freedom
Scientific left something out or is doing something wrong.

-----Original Message-----
From: nfbcs [mailto:nfbcs-bounces at nfbnet.org] On Behalf Of Jim Barbour
Sent: Tuesday, March 04, 2014 5:13 PM
To: NFB in Computer Science Mailing List
Subject: Re: [nfbcs] My Opinion and Experiences with Accessibility

I think the question is valid.

Firefox does support accessibility.  I will say that some pages that work
with firefox don't work with IE and vice versa.

What are people's experiences with windows chrome?

Jim

On Tue, Mar 04, 2014 at 06:04:44PM -0700, Suzanne Germano wrote:
> I was asking a serious question on if firefox does or does not support 
> accessibility.
> 
> It is actually fact that most people use firefox that is why I ask.
> 
> I did not know person opinion we not allowed to be expressed on here.
> People have different preferences.
> 
> 
> On Tue, Mar 4, 2014 at 5:44 PM, Mike Freeman <k7uij at panix.com> wrote:
> 
> > Let's keep personal opinions out of this. I happen to like IE.
> >
> > Mike Freeman
> >
> >
> > -----Original Message-----
> > From: nfbcs [mailto:nfbcs-bounces at nfbnet.org] On Behalf Of Suzanne 
> > Germano
> > Sent: Tuesday, March 04, 2014 4:12 PM
> > To: NFB in Computer Science Mailing List
> > Subject: Re: [nfbcs] My Opinion and Experiences with Accessibility
> >
> > Does firefox not support accessibility? I use magnification so I 
> > don't know what is available or not available for screen readers.
> >
> > I do know most people use firefox. IE sucks. I don't use safari on 
> > my mac or IE when I am on my windows VM.
> >
> >
> > On Tue, Mar 4, 2014 at 4:02 PM, Aaron Cannon < 
> > cannona at fireantproductions.com
> > > wrote:
> >
> > > Hi Dave and all.
> > >
> > > While I completely agree with your second point  in principal, 
> > > putting this in to practice could result in a site which is only 
> > > technically accessible, but not actually accessible.
> > >
> > > Most organizations which I've helped with accessibility
> > > (understandably) have wanted to make their sites actually accessible.
> > > However, they've also not wanted or had the resources to support a 
> > > wide variety of browser/screen reader combinations.  So what's 
> > > usually happened is that they've picked the most popular screen 
> > > reader (or if we're lucky screen readers), which usually end up 
> > > being Jaws and Voiceover, and test them with their site in IE and 
> > > Safari respectively.
> > >
> > > The company I'm working for now has just decided to begin 
> > > tentatively supporting NVDA in Firefox, in addition to our current 
> > > support of Voiceover with Safari and Jaws with IE.  Hopefully this 
> > > won't create much more work for the devs.
> > >
> > > The only way out of this mess (IMHO) is for browser vendors to 
> > > collaborate more closely to standardize their accessibility APIs, 
> > > and for screen reader manufacturers to work more effectively to 
> > > insure that their products are supporting all the browser API has to
offer.
> > > Given the fact that there are still differences in how browsers 
> > > render CSS and support JavaScript, I'm surprised that the 
> > > accessibility support is as consistent as it is.
> > >
> > > Aaron
> > >
> > > On 3/4/14, David Andrews <dandrews at visi.com> wrote:
> > > > I don't want to sound argumentative, but I don't agree with 
> > > > everything below.  First, this is a very blind-centric view of 
> > > > web accessibility.  There is more to it then us, and many people 
> > > > loose sight (no pun intended,) of this point.  Secondly, I don't 
> > > > think it is reasonable for a developer to have to test with all 
> > > > screen readers.  She/he would also need to test each screen 
> > > > reader with all possible browsers.  Everything, unfortunately, 
> > > > behaves differently.  All a developer can do is code to 
> > > > standards, like WCAG 2.0.  Otherwise she will drive herself 
> > > > crazy if you try to code for screen reader bugs or poor
implementations.
> > > >
> > > > Dave
> > > >
> > > >
> > > > At 10:38 PM 3/3/2014, you wrote:
> > > >>This email is in response to some of the threads that have been 
> > > >>going
> > on
> > > >>over the last two or three days. I have separated it out, 
> > > >>though,
> > because
> > > >> I
> > > >>hope that people will read it in it's own light instead of in 
> > > >>the
> > direct
> > > >>shadow of some of the other messages.
> > > >>This message might get a little lengthy, and I might have to 
> > > >>finish it another time. The following are my opinions, which are 
> > > >>based off of my experiences. Feel free to dispute them, but I 
> > > >>ask that you please do it
> > > in
> > > >> a
> > > >>polite manner. So, here goes...
> > > >>Oh, and one other thing. All of this is in reference to web
> > > accessibility,
> > > >>since that is the area with which I am most accessible.
> > > >>
> > > >>It may be hard to define accessibility, but I think that it is 
> > > >>possible
> > > to
> > > >>have at least some sort of definition. To start, accessibility 
> > > >>means
> > that
> > > >> it
> > > >>can be used with a screen reader. Okay, so what does "can be 
> > > >>used with
> > a
> > > >>screen reader" mean? This might not be all of it, but, as a 
> > > >>start for defining  guide lines for developers, it is better than
nothing:
> > > >>1. Everything that can be achieved with the mouse can be 
> > > >>achieved with  only the keyboard 2. Focus is handled correctly 
> > > >>3. ARIA roles and attributes are used and maintained correctly 
> > > >>4. HTML elements are used correctly This might not seem like a 
> > > >>lot, but these four areas have a lot of  content.
> > > >>For example, JMHO, number 3 covers issues like notifying the 
> > > >>screen
> > > reader
> > > >>when an area of the web page changes using aria-live. Number 4 
> > > >>could  include things like using headings when appropriate and 
> > > >>not using tables purely  for layout purposes with stuff that is 
> > > >>not data.
> > > >>
> > > >>I don't think that developers deliberately decide to make their
> > websites
> > > >>inaccessible. A lot of developers don't know how to make their 
> > > >>websites accessible. Not everyone knows about ARIA, and, even if 
> > > >>they do, there
> > is
> > > >>not a good way to verify that all of the ARIA stuff is correct 
> > > >>without  using a screen reader. Even if a screen reader is used 
> > > >>to test a website,
> > most
> > > >>sighted developers don't have the screen reader proficiency that 
> > > >>we do,  and, even if they do, they might only have access to 
> > > >>certain screen readers,
> > > so
> > > >>there is no way to verify that it works with all screen readers. 
> > > >>I
> > can't
> > > >>tell you how often I test something with screen reader x, and 
> > > >>the  developer says "I don't understand. I tried it with y or z, 
> > > >>and it worked."
> > > Usually,
> > > >>once I explain, they understand, but it is extremely frustrating 
> > > >>for
> > them
> > > >>when they put in the time and effort to test, but find out that 
> > > >>it does  not work with a certain screen reader. To that end, 
> > > >>some of the
> > accessibility
> > > >>problems are because screen readers act different and implement 
> > > >>the
> > ARIA
> > > >>spec differently. I'm not suggesting that all screen readers 
> > > >>should be
> > > the
> > > >>same, but there are certain things that would make things easier 
> > > >>if the  were consistent across screen readers. I also often run 
> > > >>into the case where
> > > the
> > > >>developer has tried, having good intensions, but has 
> > > >>misunderstood what certain ARIA attributes do. JMHO, the ARIA 
> > > >>spec needs to give more information.
> > > >>Accessibility might not be the absolute first thing on the list 
> > > >>when a product is created, but it needs to be on there fairly 
> > > >>early, long
> > before
> > > >>dogfood or even fish food. Accessibility is not something that 
> > > >>can be  added later. The analogy that I like to use is adding 
> > > >>ramps and elevators to
> > a
> > > >>building after it is built. It just does not work, or not that well.
> > Even
> > > >>though accessibility may not affect that many people, it needs 
> > > >>to be  treated the same way that security is treated; it needs 
> > > >>to be a "launch
> > blocker".
> > > >>Okay, so maybe it is not realistic to expect a product to be 
> > > >>absolutely perfect in terms of accessibility before it sees the 
> > > >>light of day. Then  how do you determine what is enough? You 
> > > >>make levels of accessibility,  starting simply with item number 
> > > >>one on the list above. No, it's often not
> > enough
> > > >> for
> > > >>good screen reader support, and it usually keeps people from 
> > > >>coding themselves into a corner. There could be different levels 
> > > >>of  accessibility.
> > > >>If a product is large, then different levels could be assigned 
> > > >>to  different parts of the product based on how often that part 
> > > >>is used.
> > > >>In order for a product to be accessible, it sometimes takes the 
> > > >>entire company being committed to accessibility. Sometimes, 
> > > >>developers want to  make the product accessibility, but they 
> > > >>think or have been told to focus
> > > their
> > > >>efforts in other areas. So, often, the best approach is a top 
> > > >>down  approach.
> > > >>If someone high enough in the chain can be convinced that 
> > > >>accessibility
> > > is
> > > >>important, then he/she will tell the people whom they manage to 
> > > >>work
> > more
> > > >> on
> > > >>accessibility.
> > > >>Unfortunately, there is no quick and dirty guide to making a 
> > > >>website accessibility. If you want to make it really accessible 
> > > >>the rather easy  way, then just use native HTML, but, in today's 
> > > >>world, that just does not  scale.
> > > >>Developers need to understand ARIA roles and attributes, 
> > > >>keyboard  handling, and focus handling. They also need to 
> > > >>understand what screen readers  cannot do, such as detect most 
> > > >>CSS or recognize images.
> > > >>Finally, yes, often, the best way to test a product for 
> > > >>accessibility
> > is
> > > >> to
> > > >>have users with disabilities try it. If a company is large 
> > > >>enough,
> > there
> > > >> may
> > > >>be a fair number of employees with disabilities. Also, there are
> > > sometimes
> > > >>employees who do not have disabilities but who work on 
> > > >>accessibility
> > who
> > > >>know how to use assistive technology, but these are probably not 
> > > >>as prevalent in smaller companies.
> > > >
> > > >
> > > > _______________________________________________
> > > > nfbcs mailing list
> > > > nfbcs at nfbnet.org
> > > > http://nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
> > > > To unsubscribe, change your list options or get your account 
> > > > info for
> > > > nfbcs:
> > > >
> > >
> >
> > http://nfbnet.org/mailman/options/nfbcs_nfbnet.org/cannona%40fireant
> > producti
> > ons.com
> > > >
> > >
> > > _______________________________________________
> > > nfbcs mailing list
> > > nfbcs at nfbnet.org
> > > http://nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
> > > To unsubscribe, change your list options or get your account info 
> > > for
> > > nfbcs:
> > > http://nfbnet.org/mailman/options/nfbcs_nfbnet.org/sgermano%40asu.
> > > edu
> > >
> > _______________________________________________
> > nfbcs mailing list
> > nfbcs at nfbnet.org
> > http://nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
> > To unsubscribe, change your list options or get your account info 
> > for
> > nfbcs:
> > http://nfbnet.org/mailman/options/nfbcs_nfbnet.org/k7uij%40panix.com
> >
> >
> > _______________________________________________
> > nfbcs mailing list
> > nfbcs at nfbnet.org
> > http://nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
> > To unsubscribe, change your list options or get your account info 
> > for
> > nfbcs:
> > http://nfbnet.org/mailman/options/nfbcs_nfbnet.org/sgermano%40asu.ed
> > u
> >
> _______________________________________________
> nfbcs mailing list
> nfbcs at nfbnet.org
> http://nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
> To unsubscribe, change your list options or get your account info for
nfbcs:
> http://nfbnet.org/mailman/options/nfbcs_nfbnet.org/jbar%40barcore.com
> 

_______________________________________________
nfbcs mailing list
nfbcs at nfbnet.org
http://nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
To unsubscribe, change your list options or get your account info for nfbcs:
http://nfbnet.org/mailman/options/nfbcs_nfbnet.org/ntorcolini%40wavecable.co
m

More information about the NFBCS mailing list