Re: Structure vs. Value and Contradictory Criteria

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