Re: Structure vs. Value and Contradictory Criteria

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