W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2014

Re: Success criteria speak for themselves

From: Wayne Dick <waynedick@knowbility.org>
Date: Wed, 19 Feb 2014 11:55:21 -0800
Message-ID: <53050C29.1020207@knowbility.org>
To: w3c-wai-ig@w3.org
Dear WAI-IG Friends,

I really appreciate your comments on my 1.3.1 example.  I chose the 
example because Turing undecidability is a sure example of something 
that cannot be programmatically determined.  I am sure WCAG WG intended 
a less restrictive interpretation of programmatic determinism, but this 
example certainly meets the challenge.

The issue of style level semantics is deep and not well covered by WCAG 
or ARIA.  When ARIA was developed arbitrary user interface applications 
were being tied to semantically empty container elements like DIV and 
SPAN.  This disabled assistive technology, and ARIA was the filler.  
This was a period when CSS was fairly straight forward, and text was not 
being routinely supplied by procedurally based applications or generated 
content like it is today. The issue of semantics conveyed by style was 
also overlooked. I ask this. Why don't we supply semantic markers like 
ARIA roles to semantically empty elements like DIV and SPAN that are 
used to style text for semantic reasons?

The problem facing people with low vision today is this.  Screen 
magnification is not a good user interface by any objective standards, 
but it is the only interface that most people can manage. I write my own 
style sheets to read, but most people with low vision can't do that. The 
moderately technical person with low vision today faces a web that is 
tailored to fully sighted users. This means that stylistic idioms are 
not designed with low vision in mind.  Many don't work, and many don't 
provide enough information to support reading with limited vision.

The mapping of style to meaning is not one to one. So it can elude 
programmatic detection. Italics, for example, have multiple mappings to 
usage, so effective programmatic transformations are difficult to manage 
in totally stylistic terms. The necessary task of translating italics to 
a more readable format is a simple programmatic solution, but is this 
enough?  Why do we use stylistic semantics?

One reason for stylistic semantics is to facilitate visual scanning.  We 
read a definition and now we have to find it.  With full sight italics 
might be enough of a cue to locate a definition, but with partial sight 
will the scanning function be served?  Maybe wrapping every definition 
in brackets would help.  If an element were identified by a DFN element 
it could be displayed in a readable font face that stands out from the 
running text using "font-family" and it could be surrounded in brackets 
using generated content. That would really stand out, and it would 
distinguish it from other usages of italics.  In the case of a SPAN 
element with "font-style" set to "italic" no such distinction would be 

Anyway, for any of you going to CSUN this march, we can have a discussion.

Received on Wednesday, 19 February 2014 19:55:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:50 UTC