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: Birkir R. Gunnarsson
Date: May 13, 2012 8:02AM

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
>
>
> > > >