Re: Structure vs. Value and Contradictory Criteria

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