Re: Responsive Design should be required

Opps, I meant 2004, not 1994. There was no CSS in 1994.

On Fri, Jul 3, 2015 at 1:38 AM, Wayne Dick <wayneedick@gmail.com> wrote:

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