- From: Wayne Dick <waynedick@knowbility.org>
- Date: Wed, 27 May 2015 09:13:50 -0700
- To: Phill Jenkins <pjenkins@us.ibm.com>, WAI Interest Group <w3c-wai-ig@w3.org>, Jonathan Avila <jon.avila@ssbbartgroup.com>
- Message-ID: <CAC9gL767eyYM=_AaBb8cnRAwEQ6rx=ccYXqaHfOFF4r96yWyPg@mail.gmail.com>
Dear Phill, I will write you a more detailed letter on why internal application adaptation is much better than for several types of low vision. To answer your big question. Yes, I want federally protected access to change only the presentation of from within applications that support reading and writing. But, before I get to assistive technology let me explain why my new fail cases imply failure of 1.3.1 or 1.3.2. For my logic I use only definitions from WCAG 2.0 and the exact wording of 1.3.1 and 1.3.2. I do use the fact that Turing undecidability does imply lack of programmatic non-determinism. Fail Case 1: [This was 1194.22(d). It required a page to be functional without its style sheet. Mine is stronger it requires any presentation specification to be removed. ] Content that fails this criteria includes content that is not perceivable, not operable or not understandable without support of presentation. This means that the information, relationships and structures that make the page work are buried in presentation. The only way to find these issues programmatically is to determine the meaning of the underlying program code of the pate. That is that is formally undecidable process (Turing, The Halting Problem) and hence cannot be programmatically determined. Fail Case 2: A page cannot be linearized by removing presentation implies: (1) failure of Fail Case 1 (and 1.3.1), (2) the content contains tables, or (3) the reading sequence fails. (There are some CSS 3 rules that permit browser choice of formatting form elements. Perhaps some of these may interfere with linear flow, but I have never had problems.). If a table depends on a table structure to express its meaning (a function) then it should not be linearized (the exception). Otherwise the table is for layout and the New Fail Case prohibits those configurations. Finally, if the reading order is disrupted then the content already fails Fail 1 for SC 1.3.2. Fail Case 3: [I can only demonstrate this with HTML / CSS / JavaScript pages.] One can write a reset style sheet that sets every element to its browser default style. The code of this can be followed by user preferences of for font, color, spacing and line length, even column format. If this cannot be done then the page fails Fail Case 1. I will address AT in subsequent email. I am a little hesitant about criticizing ZoomText, Magic and Luna on the list. They do a superb job for many audiences, especially visual readers with sever and profound low vision. Many people who can read between 24 to 72 point font are not well served by this software. Properly structured content (ie. does not 1.3.1 or 1.3.2) would address this issue. All I am asking is that people in the mid range of low vision are given the well structured data they need to access the rendering capabilities of their user agent. At the time WCAG 2.0 was written this seemed impossible, but mobile phones showed that it is in easy reach. Wayne
Received on Wednesday, 27 May 2015 16:14:18 UTC