[nfbcs] My Opinion and Experiences with Accessibility

Tue Mar 4 18:36:30 UTC 2014

What's interesting about this is that the same problems exist for l18n
and l10n (internationalization and localization)

There's no way to automate the testing of deploying a website in a new
language.  You can automate some of the translation, but there's
usually a lot more to it.

One difference, as Mike has pointed out, is that there's a lot of
business to be generated in other languages; but not so much business
to be generated from the blind community.

Jim

On Tue, Mar 04, 2014 at 12:22:24PM -0600, Aaron Cannon wrote:
> Hi John and all.
> 
> The government standards for web accessibility, Section 508, are
> unfortunately very out of date.  You are right to be cautious to
> recommend them.  They've been working on revising them, but it's going
> quite slowly.  However, the last I heard, they were going to largely
> adopt the WCAG 2.0 standards.  I'm not sure if that's still the case.
> 
> As for automated accessibility testing, I am very wherry.  While such
> tools can help identify potential issues, they can and do have
> frequent false positives and can also miss many types of issues.
> Since good web accessibility is largely an extension of good
> usability, and since there is not a realistic means of automatically
> testing a site for good usability, I suspect that web accessibility
> will be largely a human guided activity for quite some time.
> 
> In other words, if a developer doesn't understand how to do
> accessibility, an automated tool isn't likely to be of much help.
> Where automated tools can be useful is in helping the web
> accessibility professional or savvy developer quickly scan for certain
> types of issues.  In short, as a time saver.
> 
> Aaron
> 
> On 3/4/14, John G. Heim <jheim at math.wisc.edu> wrote:
> > The first thing than any web developer needs to know is that a lot of
> > very smart people have spent a lot of time and effort creating
> > documentation on how to write accessible web apps. For more information
> > on this, see the web site of the Web Access Initiative,
> > http://www.w3.org/WAI/.
> >
> > Also, the Federal government developed it's own guidelines for web
> > accessibility so that  developers working for the Federal government
> > could provide apps that acheived at least a certain level of
> > accessibility.  I have to admit here that I haven't read those standards
> > for about 15 years and i have no idea how up to date they are.
> >
> > You don't need a license or anything to be a web developer so many,
> > perhaps most, developers have never heard of the W3C  much less WAI. But
> > I was first introduced to the WAI back in the late 90s. It's been around
> > for a long time. One of the major criticisms of the WAI has always been
> > that it's recommendations are too long, too technical, and too difficult
> > to understand. Well, I don't know. I guess I'd consider that a valid
> > criticism. I feel it's a bit of a cop out but I can understand it. On
> > the other hand,  there are also many free and open source tools for
> > testing web accessibility. The problem is more one of selecting a tool
> > rather than finding a tool.  The University of Wisconsin just did an
> > extensive study of these tools. I'm not entirely sure the results are
> > meant for the general public but I'll check into whether i can post
> > their findings here.
> >
> > So there is no reason for us to create our own accessibility guidelines.
> >   It's being done by people who get paid to do just that. And there is
> > no reason for us to figure out how to test accessibility. There are
> > many, many tools out there to do it already. There are plenty of
> > commercial packages as well. And there are plenty of consultatnts as well.
> >
> > I guess I can agree that most developers don't make their web sites
> > inaccessible on purpose. On the other hand, I think it's all too common
> > for a developer to choose to learn about accessibility tomorrow. I was
> > once part of the team that enforced accessibility standards at the
> > University of Wisconsin. Often, when i informed a developer that his
> > site wasn't up to the University's accessibility standards, I was  met
> > with anger. "Why didn't  somebody tell me about this before?" But if the
> > guy (and it was always a guy) was being a real SOB, I'd almost always be
> > able to point out to him that he'd heard about these standards and had,
> > at some point, made a deliberate choice to postpone learning about them.
> >   It's human nature.
> >
> > But again, it's like security issues. Developers simply have to pay
> > attention to these issues or they are not doing their jobs. It's part of
> > every developers job whether they are willing to accept it or not.
> >
> >
> >
> >
> > On 03/03/14 22:38, Nicole Torcolini 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/jheim%40math.wisc.edu
> >>
> >
> > --
> > ---
> > John G. Heim, 608-263-4189, jheim at math.wisc.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/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/jbar%40barcore.com
> 