Re: Success criteria speak for themselves

Hi, Wayne and all,

Semantics != programmatically determinable
Sighted user != blind user != low vision user

What I mean with these two expressions is that there is no way to 
completely translate visual interfaces to HTML semantics. Maybe some UI 
components have a more-or-less equivlante, but in most cases the 
translation is more a metaphor than a real equivalent.

In this particular case maybe there is an element that could give more 
semantics and a similar information, but blind users could also identify 
the "italics" using reading schemes in JAWS, for example, or low vision 
users could simply not change the designer's interface and also receive 
the visual info. Indeed, most sighted users do not receive "this is a 
term with a definition in this paragraph", they must follow an 
intellectual reasoning to discover that the word in italics is the 
defined term of the paragraph once they finish reading it.

Moreover, if we consider that the "determinism" is lost just because the 
user is able to customize the styles overriding the designer's 
preference, then we have a real problem with determinism. Some examples:

What if the user decides to style lists and list elements with custom 
styles? Then the user will probably lose the difference between the main 
menu, the toolbars, the sidebar, the footer, a list within the content, 
social network buttons, etc. However, these navigation structures could 
have proper navigation roles and @aria-label attributes to identify each 
type of list. Theoretically, the user is just translating "lists" into 
his own concept of what a list should look like, but he is also 
destroying the visual clues.

Or what if the user decides to style headings with a particular font 
size and colour? It is possible that the page is based in HTML5 and 
every heading is an <h1>. Even if the user implements somehow the HTML5 
Outline algorythm, it is possible that the visual aspect of the page 
does not really convey the intended visual structure (which can be also 
conveyed to a screen reader user through sections and @aria-label).


Yes, semantics *could* help in the determinism, but they are not *the* 
only way to allow it. Moreover, using semantics doesn't guarantee any 
better determinism in terms of accessibility support. For example, most 
screen readers do not announce anything special nor allow navigation for 
<b>, <i>, <u>, <s>, <em>, <strong>, <sub>, <sup>, <kbd>, <var>, <code>, 
<dfn>, <samp> and probably others.

Should they be announced to the user? Probably not if you want an usable 
-readable- website, but the fact is that the screen reader -JAWS- user 
can only rely on default styles and special reading schemes (and he must 
configure it to do so). Even with this best-case scenario, no semantics 
are conveyed, only styles (that, in reality, are exact equivalents to 
the visual information).

It is a pity that CSUN is so far away from Spain, I would love to 
discuss these really interesting topic face to face <smile>

Cheers!
Ramón.


Wayne wrote:

> 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 
> possible.
> 
> Anyway, for any of you going to CSUN this march, we can have a discussion.
> Wayne

-- 
Ramón Corominas
Accessibility specialist
Technosite - Fundación ONCE
E: rcorominas@technosite.es
T: @ramoncorominas
P: +34 91 121 0330
W: http://technosite.es

Received on Wednesday, 19 February 2014 22:49:33 UTC