Re: Structure vs. Value and Contradictory Criteria

​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
>
>
>
>
>
>
>
>