Re: Success criteria speak for themselves

Hi, Jonathan and all,

[Ramon] or low vision users could simply not change the designer's 
interface and also receive the visual info

[Jonathan] 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.

Ouch! Please do not interpret my words that way, I am not attacking any 
civil rights here <wink>


[Jonathan] That may mean increasing the size of the text, or changing 
individual display attributes of the text.

Since I *do* have low vision, I think I am quite aware of what changing 
the interface means, including settings for font-sizes and typography, 
colours, highlighting of headings and other structures, focus 
enhancements, form field borders and visual identification, link 
underlining, justification and line-spacing of text, etc.

So I am not saying that users should not change the interface, what I'm 
saying is that certain changes can destroy visual clues that are present 
in the original design. "Determinability" is not equivalent to 
"semantics", and many design conventions or visual clues are difficult 
to convey to users that cannot see them. For example, design can be 
modern or classic, intense or quiet, funny or serious... And we don't 
have a simple way to convey these moods to a blind user, apart from the 
general tone of the text.

Wayne: I think you have here a really interesting topic for your talk... 
Shouldn't the mood of the page be "programmatically determinable"? Isn't 
an essential part of the "visual information" of a page? <wink>


[Jonathan] 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.

Maybe, or maybe not. Depending on the type of "highlighting" that the 
user decides to apply. For example, for headings within the text of an 
article it can be helpful to establish certain font-sizes or 
left-paddings that help to identify the article's structure. However, if 
these same custom styles are applied to headings for other UI elements, 
the original visual clues can be destroyed and lead to more confusion 
for the low vision user.

For example, a designer may use <h2> to markup "main menu", "search 
utils", "toolbar", "Latest posts" and so on. In my opinion, this makes 
sense for a blind user, but if the low vision user establishes the same 
font-size for those <h2> than for the text in the article, this change 
is probably generating a visual "importance" (= hierarchy) for those 
headings that they really do not have. Should we take this into account 
and mark them as <h3> or <h4>, thus skipping levels? Should every 
level-X heading have always the same size (or even visibility)?

With this in mind, let me turn back to my sentence: "low vision users 
could simply not change the designer's interface and also receive the 
visual info".

As a low vision user, I have many ways to style headings in a way that I 
can identify them. For example, I can set custom typographies or 
colours, add special outline effects, change them to uppercase, add 
margins/paddings, etc. In general, all these effects will allow me to 
identify the headings or even their levels without essentially changing 
the original design.

However, if I apply fixed font-sizes for every level-X heading 
regardless of their context, I am eliminating the original visual 
hierarchy, which may be different to the "programmatically determinable" 
structure. This is because visual design often conveys other hierarchies 
that cannot be easily translated to any HTML semantics, although of 
course we must do our best to convey a *meaningful* structure.


[Jonathan] 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.

Unfortunately, I guess this is an issue that cannot be addressed with 
CSS only. An <hx> != <h1> in different sections of the same depth can 
end up being of different level in terms of the outline, so I don't see 
how to address this without at least using JS. Example:

<main>
   <h1>I am level-1</h1>
   <section>
     <h2>I am level-2</h2>
   </section>
   <section>
     <h1>I am also level-2</h1>

     <h2>So I ended up being level-3</h2>
   </section>
</main>


[Jonathan] 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.

That is exactly what I am saying. If we consider that the 
"programmatically determinable" concept requires a strict interpretation 
so everyone receives the same information, then @aria-label cannot be 
used to meet SC 1.3.1, since the information that it conveys is lost for 
non-screenreader users. Many other techniques that we are accepting 
should also be revised (for example, @title attribute would never be a 
valid way to label a form field). In any case, @aria-label is probably 
giving more information to the blind user than the visual information 
given to sighted users.

As a side note, there are no ARIA roles to convey the semantics of many 
of the text-level HTML elements... Do you consider this a bug of the 
ARIA spec? Should we add those equivalent roles to ARIA?

In the other hand, there may be other ways to convey semantics that do 
not imply HTML tags or ARIA roles, such as microdata, microformats, web 
components... In principle they might lead to "programmatically 
determinable" ways of conveying the visual info, but the real issue will 
always be the lack of accessibility support, not the semantics.


[Jonathan] 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.

Of course, but "understandable" is different from "exactly the same". My 
point in this thread is that a <dfn> -or similar- tag might convey 
*more* information to the blind user than the visual styling is doing to 
the sighted user. The sighted user must deduce that the italicized word 
ia a definition term *after* reading the text. The reality is that <dfn> 
and similar tags have no accessibility support (nor specific roles), so 
in the Real World it is irrelevant -for blind users- if we mark these 
contents as simple spans.

In summary, although semantics can help to achieve determinability they 
do not guarantee it; and conversely, the lack of semantics does not 
necessarily prevent determinability.

Regards,
Ramón.

Received on Thursday, 20 February 2014 23:55:48 UTC