WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Guidelines are only half of the story: accessibility problems encountered by blind users on the web

for

From: Bryan Garaventa
Date: May 13, 2012 1:51PM

It's true that there are many facets to accessibility.

User familiarity and experience with Assistive Technologies is one facet,
which is a viewpoint that can easily be exploited by simply putting an SEP
(Somebody Else's Problem) field around it from a business standpoint, which
isn't helpful to anyone.

Another facet is standardization using guidelines and requirements, which
are helpful. The problem is that they address issues from a symptomatic
standpoint, so that, in many cases, from a business standpoint, problems
aren't considered to be problems until someone complains about them. We,
here, know what isn't working and why it's not, so we can be pretty voluble
about pointing these things out to the right people. The vast majority of AT
users however just know that something is wrong and they can't find what
they are looking for, so they just leave and go somewhere else where things
are less confusing. This happens not just for AT users, but for everyone.
Most people don't report issues they come across from day to day, either
because they don't know who to report it to, they don't have time, they
figure somebody else has already reported it, or they simply don't want to
do so.

Also, addressing issues at a symptomatic level isn't scalable, which is a
huge problem that comes up over and over. What happens in these cases, is
that you have the home pages of complex sites, and some critical path pages
such as registration, login, account preferences (maybe), and so on, that
have properly implemented standards, but then when you explore further into
other regions, you find spotty standard compliance and sometimes none at
all.

The concept that is missing, which is growing larger as time goes on, is
that many complex websites are evolving into complex web services, which is
vastly increasing the number of ways to implement interactive features in
ways that completely overlook accessibility. For example, there are
thousands of ways of dynamically rendering content on a page that is not
accessible, but there are definitive ways of doing it that ensure the
highest level of accessibility. To clarify, web services usually contain
many interactive features that exist within one page, that dynamically pull
content into the page as needed based on user interaction. This is valuable
in that it provides a feature rich environment for interactivity, and it
greatly reduces bandwidth overhead since small amounts of content are being
loaded instead of full pages every time queries are made, which increases
the speed of these services as well.

So the missing facet is a structured framework where dynamic content can be
easily managed in a scalable fashion, so that the accessibility of these
features can be implemented by default, instead of trying to do it as a
symptomatic afterthought. This will enforce proper coding techniques to
ensure accessibility, and will ensure scalability across millions of
webpages.

I think we're getting hung up on the details regarding blind versus not, and
the tagging of the PDF.
Standards and requirements will always be important to provide structured
guidelines for developers.

Nevertheless, standards by themselves are not going to be enough to enforce
a scalable level of accessibility within evolving coding structures without
a framework for this purpose, which takes the guesswork out of the rendering
process for developers unfamiliar with Assistive Technologies.

Without a structured coding framework for this purpose, accessibility will
forever be chasing the latest innovations in web technology development, and
complaining loudly that it doesn't work for everyone.

The only workable solution for this situation, is to merge accessibility
with the development of web technologies so that future innovations already
have an accessible platform from which to work. Then the standards can be
used to fine tune the accessibility of individual features to maximize the
user experiences for everyone.

----- Original Message -----
From: "Birkir R. Gunnarsson" < <EMAIL REMOVED> >
To: < <EMAIL REMOVED> >; "WebAIM Discussion List"
< <EMAIL REMOVED> >
Sent: Sunday, May 13, 2012 7:02 AM
Subject: Re: [WebAIM] Guidelines are only half of the story: accessibility
problems encountered by blind users on the web


At the risk of repeating myself, I agree with all of the excellent
points in the preceeding mail, but must also wonder about user
training or techniques.
Do they know what headings are, and do they use headings to try and
make sense of the page.
Do they use landmarks as a back up to try and analyze the page's
logical structure?
A more interesting study would be to analyze their techniques and try
and come up with a best-method plan to teach users to methodically
look for information on web pages.
Having come up with an algorithm like that, apply that to the pages in
question to see how well it would do at locating information on those
pages.
For instance, how accessible would you find this page if you did not
try to jump directly to heading level 1?
http://www.brandonsanderson.com/blog/1084/More-Creative-Writing-Lectures--Updates
(it would take you almost 80 arrow down presses to get to this
article, if you do not try to interact with the page structure you
would've given up by then, or at least not view the page favorably).

Could the screen readers do a better job of presenting pages to the
users (for example, by indicating colors and layout of the page in
some fashion, I have personally always found that one of the missing
features in all screen readers.

I find all of these 6 points not something that accessibility guide
lines could or should address specifically.
And while i totally agree with Bryan on the main point -- that we need
to somehow be more proactive about accessibility and use technology
better to incorporate accessibility out of the box in technical tools
(also addressed, at lesat in part, by ATAG)-- I don't find this report
particularlly convincing, nor do I agree with all its methods and
findings.
It places too much responsibility on the website designers and not on
the users or assistive technology they deploy, to say nothing of the
screen reader being used as the only assistive technology being
tested. It is a good usability study, but not a good accessibility
one, in my view.

The fact that the Pdf of the report itself is untagged also really
does a lot to make me lose faith in what the authors are doing. If
they don't even know how to make an accessible report about
accessibility, how much do they really know or understand about
accessibility?
If there was no way to make the report accessible (though it appears
to me that simple tagging would've been sufficient), they should
indicate that, and appologize for it up-front.

-B

On 5/13/12, Léonie Watson < <EMAIL REMOVED> > wrote:
> It is an interesting paper to read. The idea of a set of design
> principles is also interesting. It's something we've been working on in UK
> government recently. The Gov.UK design principles are still alpha release,
> but for practical reasons inclusion has already emerged as a principle in
> its own right.
> http://www.gov.uk/designprinciples/
>
> To answer your question Andrew, I'm not sure that those six points
> can (or should) be included in a set of accessibility guidelines. Like
> most
> things it isn't that simple though, so I've put some thoughts down here.
> You
> might want to grab a cup of tea first though...
>
> 1) Content found in pages where not expected by users.
> 2) Content not found in pages where expected by users.
>
> With points 1 and 2 it's difficult to judge whether they should be
> covered by WCAG, or whether they may already be covered. There isn't
> enough
> information given in the report to explain why participants were
> surprised.
>
> Given that the report finds that they were not covered, we have to
> assume that the surprise wasn't due to poor preceding link text, poor page
> titles or other factors covered in WCAG.
>
> My guess then is that the Information Architecture (IA) is the
> underlying problem in these cases. I can't envisage how that could be
> addressed through WCAG though. Link text aside, it's a subjective
> categorisation problem that is best addressed through card sorting or some
> other usability technique isn't it?
>
> 3) Pages too slow to load.
>
> I'm not sure why this would be considered an accessibility issue.
> Obviously, if you can't get to the page you can't access it, but that's
> level right across the playing field.
>
> It also opens up a can of worms in terms of definition. Even if we
> tried to come up with a design principle, as opposed to a testable SC,
> it's
> a challenge. Too slow for whom? On which device/connection? In what
> environment/context?
>
> 4) No alternative to document format.
>
> There wasn't enough information in the report to really understand
> this point. If, as I suspect, it was largely about alternatives to PDFs, I
> wonder whether it's entirely an accessibility issue.
>
> Given that there may not be a single file format that is truly
> accessible to and usable by everyone, there could be an argument for a
> WCAG
> guideline to cover the need for alternatives. The bit I'm uncomfortable
> with
> isn't the legitimate provision of an alternative format, but the escape
> clause it opens up for less committed content authors. Perhaps I'm
> worrying
> too much though.
>
> 5) Information architecture too complex (e.g. too many steps to find
> pages).
>
> This has reflections of points 1, 2 and 3. The challenge would be
> defining a design principle or guideline that successfully encompassed
> such
> a subjective and context dependent issue.
>
> 6) Broken links
>
> This comes back to the point that if you can't access a page it
> isn't accessible by definition, but then it isn't accessible to anyone
> equally. At the risk of being flip, if we start down this path do we need
> to
> include guidelines for things like factually incorrect content as well?
>
> Taking a step back to the report itself, I understand that
> researchers need to choose a limited field of study and that the headline
> finding needs to grab attention quickly and concisely. I can't help
> feeling
> that screen reader users have once again become the poster children for
> accessibility, and that the headline is at odds with the focus of the
> report
> itself though. The real irony is that the report is an untagged PDF (which
> I've emailed one of the authors about).
>
> Léonie.
>
>
> From: Andrew Kirkpatrick
> Date: Thu, May 10 2012 2:39PM
> Subject: Re: Guidelines are only half of the story: accessibility problems
> encountered by blind users on the web
>
> The study was very interesting, but suggests an expansion on the category
> of
> accessibility which I'm interested in hearing whether people agree. I do
> agree that the issues raised in the study are problems for users, but I'm
> not convinced that they are _accessibility_ problems that need to be
> covered
> in an accessibility standard.
>
> The six categories of errors that the study identified as not having any
> WCAG 2.0 requirement to address, and the six which are covered somewhat
> are
> worth mentioning - I'd be interested in whether people agree that these
> should be part of WCAG.
>
> Not covered in WCAG 2.0:
> 1) Content found in pages where not expected by users
> 2) Content not found in pages where expected by users (example provided:
> "on
> a museum website, users followed a link to an object in the museum
> collection but did not find any information about the room in which that
> object is displayed, which they expected.")
> 3) Pages too slow to load
> 4) No alternative to document format (e.g. PDF)
> 5) Information architecture too complex (e.g. too many steps to find
> pages)
> 6) Broken links
>
> Covered at least in part by WCAG 2.0:
> 7) Functionality does not work (as expected)
> 8) Expected functionality not present
> 9) Organisation of content is inconsistent with web conventions/common
> sense
> 10) Irrelevant content before task content
> 11) Users cannot make sense of content
> 12) No/insufficient feedback to inform that actions has had an effect
>
> So, what do people think? How many of 1-6 should be added to WCAG?
>
> AWK
>
>
> > > >