[nfbcs] My Opinion and Experiences with Accessibility

Wed Mar 5 00:12:19 UTC 2014

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%40fireantproductions.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
>