[nfbcs] My Opinion and Experiences with Accessibility

Wed Mar 5 01:04:44 UTC 2014

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%40fireantproducti
> 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.edu
>