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: Steve Faulkner
Date: May 14, 2012 4:50AM

Detlev Fischer has undertaken a sobering of the study:
Methodological flaws put question mark on study of the impact of WCAG on
user problem http://www.bitvtest.eu/articles/article/lesen/chi2012-wcag.html

On 14 May 2012 11:16, Karlen Communications
< <EMAIL REMOVED> >wrote:

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



--
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html