- From: Wayne Dick <wayneedick@gmail.com>
- Date: Fri, 23 Oct 2015 13:07:34 -0700
- To: Adam Solomon <adam.solomon2@gmail.com>
- Cc: Gregg Vanderheiden <gregg@raisingthefloor.org>, GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
- Message-ID: <CAJeQ8SA0R_U9CaQXpD8Odu85muX8kNdR0k9BeVk0TLvnP00DLg@mail.gmail.com>
Oops, I should have numbered my hypothetical criteria 1.3. 4, 1.3.5, 1.3.6 respectively. On Fri, Oct 23, 2015 at 11:14 AM, Wayne Dick <wayneedick@gmail.com> wrote: > 1.3.1 would do it for everything if the normative text was actually > followed. We could solve a lot like reading the wrong abbreviation name > with screen readers and difficulty providing substitutes for italic text, > but it has been made very clear to me that the semantics of in-line text > were never intended as part of 1.3.1. So, on that matter I give up. > > To make things clear we need a 1.3.3 which states that information, > structures and relationships expressed in in-line text objects can be > programmatically determined. Also there should be a 1.3.4 that states: > Each document includes structures that enable a one column presentation > within the user agent. Such a one column representation will have full > access to all functional capabilities of the original content and the user > agent. 1.3.5 The one column representation can be enlarged to any size the > user wishes within the user agent. No horizontal scrolling will be required > unless the user desires it. If a single word is too long to fit on a line > it will be broken with the end appearing on the next line. > > Probably all of this should be implied by 1.3.1, but it is not, and > regulations is as much practice as it is wording. > > In conclusion, WCAG needs three criteria to support low vision. They are > structural, and entirely within the capability of the author and user agent > implementer. > > > > > > On Fri, Oct 23, 2015 at 2:53 AM, Adam Solomon <adam.solomon2@gmail.com> > wrote: > >> 1.3.1 as part of WCAG 2, strictly speaking would cover any aspect of >> structure-presentation, whereas the non normative documents (understanding, >> techniques) become more specific as they go along. So, when we speak about >> css3 etc, the ability to extend 1.3.1 without amendment can certainly be >> considered, with as little as adding technique documents as we did with >> HTML5 and ARIA >> >> On Fri, Oct 23, 2015 at 8:00 AM, Wayne Dick <wayneedick@gmail.com> wrote: >> >>> 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 20:08:04 UTC