W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > April to June 2018

Re: [White paper] A11Y Wars: The Accessibility Interpretation Problem

From: Wayne Dick <wayneedick@gmail.com>
Date: Mon, 21 May 2018 12:49:46 -0700
Message-ID: <CAJeQ8SCEd-AD2A40iV3FMLRgL=uU2KNeSVFQLdO4d51u5f2=Nw@mail.gmail.com>
To: alastc@gmail.com
Cc: Glenda Sims <glenda.sims@deque.com>, W3C WAI ig <w3c-wai-ig@w3.org>
Hi Glenda and Wilco,
Here are the rest of my thoughts.

A11y Wars: Review 2

Before starting I would like to repeat my appreciation of this analysis.
Superb work!

When we speak of ideal we should be sure that it is ideal. The intervention
must be proven to be effective, and, demonstrated to be achievable.
Enlargement to 400% with word wrapping is not an ideal for print on paper
because it is not possible.

One ideal that COGA and LVTF put forward in the 2.1 dialogue was
personalization. Personalization is an ideal because it is demonstratively
effective. It can also be achieved with the addition of semantic
information to content and browser extensions that interpret the new
semantics. It will be interesting to identify other ideals as we proceed.

Personalization is an ideal now, but it has extremely high priority.
Personalization is necessary for people with cognitive and low vision
disabilities to achieve literacy.

Access to literacy is high priority. Also, when a person is taking an
examination of proficiency, the need for unambiguously readable content is
essential to fair assessment. Access to commerce is also critical, as well
as technology that is necessary for employment. If a guideline that claims
accessibility does not support life functions at this priority level, one
can hardly call it accessible.

WCAG Assumptions Technology Agnostic

This goal is not an ideal because it is unattainable. People develop
technology to meet needs that are not met by other technology. Almost by
definition, this will enhance some capabilities and limit others. If we
limit our accessibility ideal to those that do not conflict with the
limitations of every technology, we will wind up with accessibility
guidelines that do not do enough to attain basic life priorities.

Let us consider the difference between PDF and HTML / CSS / JavaScript.
Both technologies support print communication, but PDF focuses on
preserving visual presentation across diverse platforms, and HTML / CSS /
JavaScript focus on conveying content across diverse platforms with some
flexibility in visual presentation. Is it possible to apply the same
personalization rules for visual content to PDF and HTML / CSS / JavaScript?
Is it possible to do the same for mobile phones and desktop computers?

Technology agnosticism needs reexamination because ideals that can be met
on one technology may be impossible on another. Guideline ideals need to
adapt to variable capabilities of technology so that user priorities can be

I had a very good friend, Alby Burke. He was a constitutional historian.
When WCAG 2.0 was about to be released, I told Alby about our goal of
unambiguous criteria. He laughed at me. Then Alby explained that law
frequently does not fits some real situations. Law must design ways to
interpret the necessary ambiguity that will occur in real cases. The
Understanding documents are examples of methods to interpret these real
ambiguities. The A11y Wars paper is another. What is certain is that we
will have ambiguity. All we can do is identify when we are at that place in
a given case, and make the best guess we can from our experienced. There
will always be disagreement because the only certainty is that ambiguity
will always occur.

This impacts the notion of testability and automated testing. It would be
great to have everything testable and even better automated, but this is
always impossible in ambiguous cases. Not only are there cases that cannot
be resolved mechanically, there are cases that cannot be resolved by any
logical process. Guidelines like the A11y Wars papers help us resolve these
issues along agreed upon lines of analysis.

When Alby laughed at me, I was hurt. It was 2008 and we had worked so long
to get this right. Looking back, I am grateful for the honesty. Alby was
not a policy writer, he was a tester of actual cases against the letter of
the law. One of the big advances in developing accessibility guidelines is
our awareness that different roles in the accessibility process will frame
the guidelines differently. What is clear to the AGWG will be opaque or
even ambiguous to a practitioner.
Congratulations Again, Wayne

On Mon, May 21, 2018 at 2:09 AM Alastair Campbell <alastc@gmail.com> wrote:

> Hi Glenda & Wilco,
> Great paper, I was nodding vigorously in several places :-)
> It's a good time to make these points, as it mixes well with some
> thoughts I've had about Silver & the direction guidelines &
> conformance could go in future.
> In some ways this builds on the levels A / AA / AAA in WCAG 2.x, so if
> in Silver those levels were removed, I don't think using
> minimum/optimised/idealised would work without the WCAG levels in
> place as well? Unless the AAA type criteria were aligned with
> 'idealised'?
> Also, there is another concept I'd like to bring-in at some stage:
> Analysis of barriers by their impact on the user-journey.
> When talking to clients, a key aspect of prioritisation for
> accessibility fixes is what impact that issue (barrier) has on the
> user-journey of the site.
> Two extreme examples would be:
> - Missing alt text on a partner logo in the footer of a website, which
> is unlikely to be noticed by any real user, and certainly doesn't
> impact their journey.
> - A keyboard in-accessible 'next' button on a form every user must
> fill in to proceed.
> Both are level A fails, but the priority of the two should be very
> different.
> At least for organisations that optimise their user-journeys for their
> target users, this type of analysis is fairly straightforward and (at
> optimised & idealised levels) maps well to whether people will
> struggle.
> Kind regards,
> -Alastair
Received on Monday, 21 May 2018 19:50:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:37:17 UTC