RE: Responsive Design should be required

Wayne et al, I also have expressed concern in the past that SC 1.3.1 does not seem to address text level semantic information.  Perhaps additional failure and sufficient techniques could be used within the existing success criteria.

Furthermore, I agree that even the accessibility community uses CSS to control the presence and non-presence of content with CSS.  I was hopeful that the HTML 5 hidden attribute would solve this issue but it does not.

In regards to the hidden attribute, the specification<http://www.w3.org/TR/html5/editing.html#the-hidden-attribute> says “Because this attribute is typically implemented using CSS, it's also possible to override it using CSS. For instance, a rule that applies 'display: block' to all elements will cancel the effects of the hidden attribute.”

and

The hidden<http://www.w3.org/TR/html5/editing.html#the-hidden-attribute> attribute must not be used to hide content that could legitimately be shown in another presentation. For example, it is incorrect to use hidden<http://www.w3.org/TR/html5/editing.html#the-hidden-attribute> to hide panels in a tabbed dialog, because the tabbed interface is merely a kind of overflow presentation — one could equally well just show all the form controls in one big page with a scrollbar. I

Even the HTML spec<http://www.w3.org/TR/html5/editing.html#the-hidden-attribute> quoted above uses the pseudo ::before to add in the word note before notes.  I consider this a WCAG issue.

p.note:before {
  content: 'Note: ';
  font-weight: bolder;
}

Jonathan

--
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>

703-637-8957 (o)
Follow us: Facebook<http://www.facebook.com/#%21/ssbbartgroup> | Twitter<http://twitter.com/#%21/SSBBARTGroup> | LinkedIn<http://www.linkedin.com/company/355266?trk=tyah> | Blog<http://www.ssbbartgroup.com/blog> | Newsletter<http://eepurl.com/O5DP>

From: Wayne Dick [mailto:wayneedick@gmail.com]
Sent: Friday, July 03, 2015 4:43 AM
To: Alastair Campbell
Cc: Gregg Vanderheiden; GLWAI Guidelines WG org
Subject: 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<mailto: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<mailto: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