Re: Responsive Design should be required

Dear Alister,

I appreciate your comments, but they do not coincide with my experience.

Maybe some on WCAG WG knew the significance of fluid format, but I spoke to
many members including two chairs, and I had to explain the significance of
conditional text modification. It was not until I read RWD that I found
anyone who thought like Silas Brown and I did in 1994. That was because for
the first time, normal readers actually could see print like we did. It is
a dramatically different perspective. Low capacity view ports must be
experienced at your own critical print size to really understand. The mobil
web did that.

If WCAG WG had understood the problem they would have included text level
semantics in Guideline 1.3. The ability for assistive technology to define
element (tag) level presentation would have been part of the adaptable
content guideline. Now that people have seen RWD you know what people like
Silas Brown and I thought you meant when you said simpler format. Many of
us with low vision read 1.3 thinking you did understand our need.

At the time WCAG was adopted one could take any HTML that satisfied US
Section 508 and apply what I called deconstructive style sheets. This was a
reset style sheet that reduced the presentation to the HTML 4 default.  One
then could write a custom style sheet and it would work [me, 2006
<http://dl.acm.org/citation.cfm?id=1127566&dl=ACM&coll=DL&CFID=689789353&CFTOKEN=44836200>].
Only layout tables baffled me. I could even write flexible style sheets for
MathML. The enlargement support was about 60pt. We could do it in 2008, but
nobody listened.

For a brief moment I thought I could move from basic accessibility and use
my training as a mathematician to address hard problems. We could have
ended a print disability for millions of people if WCAG WG had really
understood the problem.  Instead we missed the best historical opportunity
we ever had.

By, 2009 that assistive technology approach was dead. Even though a
graduate student and I wrote a plug-in to support this technique, the
opportunity had passed before we could release it. HTML with AJAX was
allowed to scramble semantics with presentation.

WCAG WG assistted this degeneration of access by asserting that "separation
of information and structure from presentation" was not equivalent to
historical interpretation of separating content from presentation: [Bingham,
1996], [G140, Example 2
<http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/G140>]. The narrow
interpretation of 1.3 that protected less flexible file formats made
precluded court challenges of HTML developers that mixed textual semantics
with presentation. I know, Lainey Feingold looked into it for me and
concluded that there was nothing she could do.

Now here is the problem: Element (tag) level access to presentation is a
necessary condition for access to visual content for many if not most
people with low vision. Content that cannot support this is inaccessible to
those people. It may be WCAG accessible, but it is not accessible to a
significant population with a well defined disability.

Screen magnification is like a local maximum in an NP optimization problem.
Flexible presentation is the global maximum, but you cannot get there if
you take the path that produced screen magnification. The external AT model
fed by an accessibility API fixed the screen reading crisis caused by the
GUI, but it does not work for element (tag) level presentation. We will
need content that is open to presentational modification by assistive
technology.

Let us not trivialize this class of intervension by labeling it "user style
sheets".  It is broader than HTML and CSS, and the people who implement it
need to be sophisticated developers of assistive technology who understand
the needs of thier target population.

Before we undertake anything like this we should undertake clinical trials
of all the treatments for the print disabilities that we propose to
reccommend. Screen magnification exists. We can produce responsive pages
for testing. Why don't we just test what works for whom.  While we are at
it we should test the efficacy of sinchronized text to speech in these
environments.  WAI could probably get a grant to do that.

Finally I would like add some personal experience. It would be convenient
if screen magnification worked, but it does not for a lot of people it
claims to help. Do you know how demoralizing it is when someone implies you
that you are failing because you are not using the assistance they gave you
correctly? When you are young you internalize it. You don't think maybe it
is the AT that is wrong.  I am old and crusty, and I have succeeded, but
when students are young they are filled with doubt. It actually took me
until I was 50 before I didn't doubt myself when someone told me I just
didn't use screen magnification correctly, and I was a doctor.

We cannot fix the problem by calling inaccessible configurations
accessible. Content that cannot readjust visually is not accessible. We
cannot keep forcing ineffective solutions on innocent people with
disabilities, just because the solutions fit our models. It is not kind.

The transition does not need to be immediate. It would be a huge change,
but we do have to begin.  Just as we did with WCAG 1.0, 508 and WCAG 2.0 we
will need to guide people through the transition.  File formats that cannot
do this now, need time to transition. WAI has to define the direction and a
reasonable path to achieve it.  It can be done if we start.

Sincerely, Wayne

 ------------------------------

[H. Bingham] “Historically, electronic manuscripts contained control codes
or macros that caused the document to be formatted in a particular way
(“specific coding”). In contrast, generic coding, which began in the late
1960s, uses descriptive tags (for example, “heading”, rather than
“format-17″). Many credit the start of the generic coding movement to a
presentation made by William Tunnicliffe, chairman of the Graphic
Communications Association (GCA) Composition Committee, during a meeting at
the Canadian Government Printing Office in September 1967: his topic — the
separation of information content of documents from their format.” [Harvey
Bingham, 12 Sep 1996]




On Fri, Jul 3, 2015 at 1:29 AM, Alastair Campbell <acampbell@nomensa.com>
wrote:

> Hi Greg,
>
> Between the authoring and user-agent side I think it is. Going down the
> list of technologies in the WCAG techniques list:
>
>    - Flash and Silverlight can have custom controls added for text-sizing
>    that (I assume) could also trigger layout changes. I think FLASH33 and SL33
>    demonstrate that.
>    - PDF, or rather Adobe reader has the re-flow layout user control,
>    which in a document context is equivalent to the ‘mobile view’ you get from
>    a zoomed RWD page. (PDF2)
>
> Not web technologies, but note that Android has always has a responsive
> approach to app layout, and Apple recently introduced that approach to
> support their growing variety of screen sizes.
>
> The document-originating technologies (HTML, PDF) make it relatively
> straightforward to accomplish, the programming-originating ones (Flash,
> Silverlight, Apps) take more work.
>
> Kind regards,
>
> -Alastair
>
>
> From: Gregg Vanderheiden
> Subject: Re: Responsive Design should be required
>
> that is a very good analysis Alastair.
>
> Even if it was available at that time however — this is only a partial
> solution for some types of content.
>
> To be required it would have to be possible across all technologies (not
> just HTML)
>
> Does this capability exist across all web technologies — or just certain
> types?
>
> *gregg*
>
>