WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Karlen Communications
Date: May 14, 2012 4:16AM

You wrote: "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."

I agree and one of the things I'm advocating for is the inclusion of
inclusive design in everything produced by teachers, faculty and students at
the primary, secondary and tertiary levels of education. Part of the problem
identified here is that we still think of inclusive education as having to
be "accommodated" for rather than "this is how we do it." We need to ensure
that all tools used in education are inclusive and that any document,
multimedia project or software/application created by any student is
inclusive in its design.

It is only then that we will stop the retro fit cycle for any digital
content or application, or service.

This in turn will drive the creation of more inclusive technologies and my
wishful thinking is that we'll look on this stage of digital evolution as a
"dark age."

http://karlencommunications.com/adobe/OntarioEducationAndAODA.pdf

As long as we have to "retrain" graduates to produce accessible digital
content and applications we'll be stuck in a retro fit cycle of
accommodation rather than one of inclusive design by default. People working
in the area of digital content and application design will continue to look
on accessibility as an add-on which is part of the current problem.

Cheers, Karen


-----Original Message-----
From: <EMAIL REMOVED>
[mailto: <EMAIL REMOVED> ] On Behalf Of Bryan Garaventa
Sent: May-13-12 3:51 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Guidelines are only half of the story: accessibility
problems encountered by blind users on the web

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--Up
dates
(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
>
>
> > > list messages to <EMAIL REMOVED>
>
messages to <EMAIL REMOVED>

messages to <EMAIL REMOVED>