- From: Wayne Dick <wayneedick@gmail.com>
- Date: Tue, 30 Jun 2015 12:44:13 -0700
- To: GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
- Message-ID: <CAJeQ8SD0jgG2OCrvCPBB91WJ1vdwmKaeUgTs-YyH9UHmnU-dzg@mail.gmail.com>
Good point. On first glance it seems unfair, but is it? Sometimes the difference between a success criterion and a statement of goal a little too subtle to put in the original proposal. Probably something like, "capable of supporting a responsive style specification," would be most accurate. In that context it is entirely fair to expect that level of accessibility. It is akin to requiring semantic markers and well define reading orders. At first it was an odious task; now it is routine. Well, its time to do some more heavy lifting. We missed this before because we couldn't see it. Now we can. We know how to fix a difficult problem for people with disabilities we missed in WCAG 2.0. When pressed by market pressure the industry acted with remarkable speed. It created a solution to small capacity view ports. That technology exists, it is time to move standards to match the change in technology. The intent of responsive design was not to help people with disabilities, it was to assist view ports with disabilities. The technology clearly treats a disability. We need guidelines to support its use so it will assist people with disabilities. It is time to list responsive design that aids enlargement and other text customizations as formal assistive technology that assists partial sight and other disabilities that benefit from visual flexibility. It is the best AT for the majority of low vision that has every existed. Wayne On Tue, Jun 30, 2015 at 7:29 AM, Wayne Dick <wayneedick@gmail.com> wrote: > Issue 2: Responsive Design is a Prerequisite for Accessibility > > Visually flexible content as represented by responsive design is an > essential component of accessibility for partial sight. To date, the > technology has been applied to small screens, but it can be applied to any > presentation that reduces screen capacity like changing font face or > increasing text size, line spacing or character spacing. For this reason, > Guideline 1.3, the adaptable content guideline, needs to be expanded to > include visually flexible content using responsive design as its guiding > model. > > In 2008, when WCAG was completed, the Mobile Web was not daily experience. > Nobody but people with low vision could see the need for responsive design. > It is not surprising that WCAG Working Group could not see responsive > content as a form of adaptable content required by Guideline 1.3. The need > for adaptable visual content was not in their working experience. It was > easy to hope that screen magnification was sufficient accessibility support. > > 2008 was before developers discovered that people would not read > shrink-to-fit webpages on small displays. In addition, people really did > not like the functionally truncated mobile version of webpages. By 2010 > that fact came through loud and clear. The result was responsive design. > Nobody considered screen magnification software for the mainstream users of > mobile webpages. It was never an option. An average mobile user just could > not master the difficult procedures needed to operate a screen magnifier, > just as more that 90% of people with low vision cannot. > > The main difference between users with low vision and mobile users is > market share. Both user groups operate with view ports that can hold small > quantities of data. Mobile screens and large print documents have between > 1/9 to 1/36 of the content capacity of laptop and desktop displays. Both > user groups require a significant simplification of presentation in order > to perceive, operate and understand content. Finally, both groups need all > of the functionality present for users who use view ports with larger > content capacity. > > At the time WCAG 2.0 was approved most drafters of the guidelines could > not perceive the problem. For those who could see the need for visually > flexible content, no clear path to the result existed. Today, people with > normal and low vision have experienced the same problem, and a large > majority of both groups have rejected screen magnification as a solution. > In light of this issue facing a majority population, a solution was found. > Inventive web developers have proven visually flexible data can be encoded > into content. No change of user agent or authoring tool was needed. > > The only task remaining for WCAG 2.x regarding visual flexibility is to > embed the capability into new Level A success criteria so that responsive > content is available to everyone. WCAG exists to serve the minority. When a > content technology exists for the majority that could eliminate significant > accessibility barriers for a well defined group of people with > disabilities, and that technology is implemented in a way that ignores > people with the very disability that could be helped most, it is the job of > the WCAG Working Group to expand the access to include everyone. > > People with low vision need the visual flexibility of responsive design. > No less really does the job. This means that the WCAG Working Group faces a > difficult task. We need to make a case and to build the institutional > support needed to put a content technology forward that will work, but this > will engender serious resistance from content producers. We know visually > flexible content works, and works well. How can we make it universal? > >
Received on Tuesday, 30 June 2015 19:44:41 UTC