RE: Success criteria speak for themselves

Hi,
I haven't thought this out very deeply. I wonder if an ARIA attribute could be created called AriaCustom, or some such name, and the text in the quotes could say whatever the developer needs to convey. This would probably be less than an optimal fix, but would also save from coming up with endless semantic hacks. Again, not totally thought out. End of brain storm.

Jim



-----Original Message-----
From: Ramón Corominas [mailto:listas@ramoncorominas.com]
Sent: Wednesday, February 19, 2014 5:49 PM
To: w3c-wai-ig@w3.org
Cc: w3c-wai-ig@w3.org
Subject: 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


________________________________

This e-mail and any attachments to it are confidential and are intended solely for use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not keep, use, disclose, copy or distribute this e-mail without the author's prior permission. The views expressed in this e-mail message do not necessarily represent the views of Highmark, its diversified business, or affiliates.

Received on Thursday, 20 February 2014 19:36:09 UTC