[nfbcs] My Opinion and Experiences with Accessibility

Wed Mar 5 02:30:33 UTC 2014

Yes, all disabilities have to be considered.
No, I don't expect the *developer* to test with all of the screen readers,
but that is why large companies have people who write the code and people
who do the testing. If there is not someone separate to do the testing, then
developers at least need to know the idiosyncrasies of certain screen
readers.

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

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/ntorcolini%40wavecable.co
m