Recently, Jeff Bishop has been blogging regarding a post made by a
sighted person that criticized how JAWS presented web pages. A blogger called isolani wrote an excellent article about such on his blog and here are
my comments about the matter.
I strongly agree with isolani’s assessment of the state of web
accessibility and that the responsibility for most web content issues
falls solidly into the lap of the web developers and the hacks they
have used to make web sites work while the standards for accessibility
have been fairly fluid over the years.
I, however, also believe that the screen reader authors/publishers
deserve some of the blame for one specific reason: namely, while most
if not all of the screen reader companies are members of ATIA and show
up at the industry association’s annual convention in Orlando, there
has been virtually no meetings between Freedom Scientific, GW Micro,
Dolphin, AI^2 and Serotek to discuss how web content should be
presented to their users in a way that web developers, even those good
guys who follow the WAI guidelines, so they can expect reasonably
consistent results no matter what AT the user with a vision impairment
might be using.
As isolani discusses his guilt for having crafted web pages in a
manner that works poorly with screen readers, I must also apologize
for my role in causing different screen readers to produce
inconsistent results on the same web page.
During my six years at HJ/FS, I strongly held the opinion that “it’s
accessible if it works with JAWS” and my input into design issues for
our Internet support actually promoted a user experience that, while I
thought it would be superior to our competition, it would, until the
competition caught up, be unique to JAWS. Today, almost three years
since I worked a day for FS, I use four different screen readers
(JAWS, Window-Eyes, System Access and orca) and each of these have
their own idiosyncratic ways of delivering web content. At FS, we
tried to follow the WAI User Agent Guidelines and would tell web
developers to read the WAI Web Content Guidelines if they wanted to be
accessible. If they wanted to be very accessible with JAWS, though,
they might do something differently in order to really shine. I would
say something similar to teams that built web browsers, steering them
away from an MSAA solution and into one that exposes a DOM which, at
that time, would only work with JAWS.
The other group of AT users and developers whom I feel own some of the
blame is those folks who insist on a lowest common denominator
solution to web sites. These people often push for alternate, “text
only” pages that a screen reader user can read without requiring their
AT to be smart enough to handle pages that, if coded to the content
guidelines, should work with all access technology products. I feel
strongly that text only, blind guy ghetto solutions are at best a
quick fix and at worst an incomplete version of the main web site.
I believe that because amazon.com added their text only interface
rather than making their entire web site comply with the guidelines
they contributed greatly to the perception that people with vision
impairments need a ghetto to live in that will shelter us from nasty
things like advertisements, long lists of information and many of the
features that people without a disability can use on the main amazon
site.
I know there are still a number of people who use SpeakUp or some
other text console based screen reader on GNU/Linux systems. They
will make the claim that because they use text only browsers that all
web sites should have some way to make a reduction of themselves so as
to work properly with ancient technology. My answer to this criticism
is that such people have access to the source code for their browsers
and that they should fix the compliance problems in the text browsers
and stop whining about progress in web standards.
As I started, I strongly agree that the majority of web accessibility
issues are the fault of web developers using odd hacks and writing
code that doesn’t comply with the guidelines. The issues with AT
companies and users above are relatively minor when compared to the
overwhelmingly huge number of poorly crafted web sites out there
today.
–End
If JAWS worked for everything, why would there be any need for other products of its kind? It definitely is the responsibility of the web designers to keep on top of what’s causing accessibility issues for their web page. There are things they can do to improve their page’s function for those who cannot see well or at all.
“The issues with AT
companies […] are relatively minor when compared to the
overwhelmingly huge number of poorly crafted web sites out there
today.”
it’s a chicken and egg thing, though. in many cases, even authors/developers who code exactly to specification (HTML/CSS) find that their sites don’t work well because AT doesn’t actually honour/understand some of the spec, opting instead for proprietary heuristics to divine structure and relationship of content when it’s actually been explicitly been defined in markup.
it’s already hard enough, as a web standards evangelist, to convince some developers of the value of using standards in the first place. having to post-fix a whole discussion on why a certain “semantic/structural” way of marking up content is better in theory, but in practice has no real-world value because AT ignores it – or worse, misinterprets it – does little to convince those developers to ditch their old WYSIWYG/tagsoup ways…
Hi Chris,
I’m Mike Davies, also known as Isofarro. I’m the author of the blog that you’re quoting. I apologise for the confusion.
I want to address one comment of yours in particular where you say, “I strongly agree with isolani’s assessment of the state of web
accessibility and that the responsibility for most web content issues
falls solidly into the lap of the web developers”.
The responsibility of most web content issues does not fall solidy into the lap of web developers.
Producing an accessible experience for users is a joint responsibility between web developers, browser vendors, and assistive technology vendors. None of the three parties can be allowed to ignore their responsibilities.
As a consequence, screen reader vendors cannot sit on their laurels
and expect web developers to work around the problems with their products. Neither should screen reader vendors tolerate inaccessible markup.
I’d recommend that screen reader users start talking to their screen reader vendors and encourage / ask / demand or insist that screen readers support the W3C’ User Agent Accessibility Guidelines.
Accessible web content is only one part of the accessible web experience.