RE: Structure vs. Value and Contradictory Criteria

Just on the aside:
I too think the current WCAG 2.0 SC(s) work well for mobile for the most part and don’t think much was missed at release time.  I am actively engaged in maturing mobile test processes which are repeatable, documented, and eventually include skills certification, and while on-device testing tools are scarce, none of that immature state of things is WCAG’s cause.



Allen Hoffman
Deputy Executive Director
The Office of Accessible Systems & Technology
Department of Homeland Security
202-447-0503 (voice)
allen.hoffman@hq.dhs.gov<mailto:allen.hoffman@hq.dhs.gov>

DHS Accessibility Helpdesk
202-447-0440 (voice)
202-447-0582 (fax)
202-447-5857 (TTY)
accessibility@dhs.gov<mailto:accessibility@dhs.gov>

This communication, along with any attachments, is covered by federal and state law governing electronic communications and may contain sensitive and legally privileged information. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, use or copying of this message is strictly prohibited.  If you have received this message in error, please reply immediately to the sender and delete this message.  Thank you.

From: Gregg Vanderheiden [mailto:gregg@raisingthefloor.org]
Sent: Sunday, October 25, 2015 4:26 PM
To: Dick
Cc: GLWAI Guidelines WG org
Subject: Re: Structure vs. Value and Contradictory Criteria



On Oct 23, 2015, at 1:00 AM, Wayne Dick <wayneedick@gmail.com<mailto:wayneedick@gmail.com>> wrote:
​evan1.3.1 is a start, but it is based on only one model of flexibility, the DOM-API-AT model of accessibility support.

1.3.1 makes no reference to the DOM model and is completely technology independent.

It requires all that you are looking for with regard to deterministic data about structure.  As for content - that is in 1.1.1.



ASIDE  NOT SPECIFIC TO THIS EMAIL
I am getting a bit tired of comments saying that WCAG WG didn’t understand mobile or touch screens etc.     We did.   We knew more about them and had been doing research on them for a decade.   The iPhone came out and there were no surprises in any of the overall interface technologies or techniques.  There were a few innovations in implementations but they only emphasized the robustness and importance of the SC.   And the iPhone was out before WCAG was completed and all of the provisions were looked at from the context of each new mobile technology as it came out.


BACK TO THIS TOPIC

1.3.1 is just as relevant as it was then and still works just as well.    It is only when other people put interpretations on what it means that are narrower than what 1.3.1 actually says that is looks narrower.

ALSO - Some of the discussion seems so look to 1.3.1 to provide what 1.1.1 provides.
 You should always look at   1.1.1 and 1.3.1 and 4.1.2  together when evaluating the question of making information programmatically determinable so that it can be re-presented as the user needs.

Thanks for your ear


gregg

----------------------------------
Gregg Vanderheiden
gregg@raisingthefloor.org<mailto:gregg@raisingthefloor.org>



On Oct 23, 2015, at 1:00 AM, Wayne Dick <wayneedick@gmail.com<mailto: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<mailto:gregg@raisingthefloor.org>> wrote:
SC  1.3.1  does require this.

gregg

----------------------------------
Gregg Vanderheiden
gregg@raisingthefloor.org<mailto:gregg@raisingthefloor.org>



On Oct 22, 2015, at 2:10 PM, Wayne Dick <wayneedick@gmail.com<mailto: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