[nfbcs] My Opinion and Experiences with Accessibility

Tue Mar 4 18:22:24 UTC 2014

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
>