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

RE: Success criteria speak for themselves

From: Jonathan Avila <jon.avila@ssbbartgroup.com>
Date: Wed, 19 Feb 2014 19:45:17 -0500
Message-ID: <cdb5ba22374edfe942d3f29ccc28ab7b@mail.gmail.com>
To: Ramón Corominas <listas@ramoncorominas.com>, w3c-wai-ig@w3.org
[Ramon wrote] or low vision users could simply not change the designer's
interface and also receive the visual info

This is a very sad but familiar comment that we hear.  The fact is people
with low vision need to change the display aspects of the interface to
have equal access -- a civil right in many countries -- to information and
communication technology.  That may mean increasing the size of the text,
or changing individual display attributes of the text.  If a user with low
vision decides to change the visual appearance of headings they would have
access to the heading levels and thus the hierarchy structure of the
document.  Granted HTML5 heading methods do cause some issues in this area
-- but that is an item that was overlooked and I believe can be addressed.

Aria-labels are of no use for users with low vision because they are not
exposed by user agents to people who aren't using screen readers. Ideally,
heading levels by themselves would communicate the proper information
without requiring the user to see certain styles.  I believe one of the
main points of HTML is to provide document structure that is separate from
presentation.  The web is not one size fits all -- its one size fits one.


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


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
> 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
> 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
> 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 Thursday, 20 February 2014 00:46:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:36:46 UTC