- From: Wayne Dick <wayneedick@gmail.com>
- Date: Thu, 22 Oct 2015 23:00:49 -0700
- To: Gregg Vanderheiden <gregg@raisingthefloor.org>, GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
- Message-ID: <CAJeQ8SDEfERgjM5UcwjqG30khFzDMej1MZtJrYtEYvg4qnLX-g@mail.gmail.com>
1.3.1 is a start, but it is based on only one model of flexibility, the DOM-API-AT model of accessibility support. The idea that deterministic data could be reformatted and displayed within the user agent was not envisioned by 1.3.1. The job today is to identify the structures that can support these transformations with user agent support and of course, assertive technology extensions of the user agent. At the time WCAG 2.0 was approved the iPhone was a little over a year old. When 1.3.1 was proposed the iPhone did not exist. WCAG WG didn't really understand just how flexible web data could be. But, we don't live in 2008 now. We live in an era where content authoring techniques have be established that enable extreme flexibility of presentation. We know that content can be authored that is efficient, does not compromise artistic freedom, and can support dramatic transformations of presentation. We can do a lot more with structural authoring criteria then we could imagine in 2008. No, 1.3.1 and 1.3.2 don't do it any more. Their scope is too narrow. We know that web developers can develop much more accessible content today by exploiting programmatically deterministic features of HTML 5 and CSS 3. Other technologies will follow if they want to survive the mobile revolution. The industry proved they could support visual flexibility presentation by enabling flexible content for normal readers on mobile devices. It is time to define content success criteria that acknowledge the change in authoring technology. Because these new criteria would focus of structural flexibility rather than specific typographic metric values, there is little likelihood that they would ever conflict with other criteria. After all, we will not pick specific values that help one group and hurt another because flexibility will enable choice of values by users. On Thu, Oct 22, 2015 at 12:13 PM, Gregg Vanderheiden < gregg@raisingthefloor.org> wrote: > SC 1.3.1 does require this. > > *gregg* > > ---------------------------------- > Gregg Vanderheiden > gregg@raisingthefloor.org > > > > > On Oct 22, 2015, at 2:10 PM, Wayne Dick <wayneedick@gmail.com> wrote: > > It might not be possible to avoid all conflict, but whenever possible > guidelines and criteria should address access to language structures and > parameter values rather than prescription of specific values. > > Since this is abstract let me be specific. Languages that can be read by > machines like HTML with CSS, PDF, Flash and Silverlight have one thing in > common. They have structures that can be determined programmatically, > otherwise machines could not read them. The structures that can be > determined programmatically can be changed with 100% accuracy. Other > structures cannot. > > Example: Tags for lists in PDF along with their meaning to the content can > be determined programmatically. The "class" attribute in is assigned a > string by the programmer, but a program cannot determine its meaning within > the context of the an HTML document. The CSS parameter "color" is given a > value that totally determines its meaning within the content. The "span" > element has non-deterministic meaning. > > WCAG should always insist that items that can be exposed deterministically > are exposed that way. This will enable change to structures and values > required for flexibility. > > Example: Overriding the authors color choices. if color is primarily > determined by foreground and background color attributes values choices > these can be changed. Problems with other non-deterministic formats. A > programmer may hide text by making text the same color as background. If > you change the colors you make something visible that should not be. This > should be a prohibited configuration. It is like using an H1 because you > like the font size. A programmer may use a background image. How does an AT > modify the foreground color. You cannot determine the background color > programmatically. Is there a deterministic way to do this or how can we > change this? > > Increasing the determinism of content seems to be a way to expand WCAG > without creating conflicts. > > Wayne > > > > > > > >
Received on Friday, 23 October 2015 06:01:19 UTC