Re: Success criteria speak for themselves

Hello, Jonathan.

[Jonathan] I think the bit that is causing others to not
understand Wayne's point is the use of dfn as an example (...)
Things like subscripts and superscripts to me are more important
because their meaning is indicated visually as a superscript or
subscript.


Completely agree, and inndeed there are many other elements that fall in 
the same category. Some examples:

1.a) Reminder: <kbd>Control Escape</kbd>! It is the key to... (the 
article talks about "Ctrl+Esc" as a key in the keyboard)

1.b) Reminder: Control <kbd>Escape</kbd>! It is the key to... (the 
article reinforces the idea that taking control of the Escape key is 
important to achieve a result)

2.a) We found a similar case in the second switch< (maybe a text about 
electricity)

2.b) We found a similar <code>case</code> in the second 
<code>switch</code> (a text about programming, maybe about programming 
electrical components...)

3.a) Her name was Anne Marie Walters...

3.b) Her name was <del>Anne</del> <ins>Marie</ins> Walters...

And of course there is a very good example with the sentence "cats are 
cute animals" in the HTML5 spec [1].


[Jonathan] CSS is for presentation only and not conveying meaning.

Although I agree, it is also true that PRESENTATION CONVEYS MEANING. 
Maybe not "pure information", but nuances or moods that may influence a 
lot in the meaning perceived by the user (and in ROI); a very simple 
example is writing in uppercase, which is interpreted as "shouting" and 
can convey a negative nuance... Did you experience a negative feeling 
reading the first sentence of this paragraph? If so, I apologise, I was 
just doing an experiment <wink>

Of course, I am not saying that WCAG should cover all of these 
"information". Nevertheless, the reality is that there are other visual 
aspects that we do usually take into account when trying to replicate 
the structure: menus, toolbars, headers, footers...


> Using the defense that others on the list have -- that current
 > assistive technology doesn't announce them or requires the user
 > to use a certain sound scheme is not a good reason to not
 > markup code according to the standards.

I haven't seen anyone defending that. In my case, what I am saying is 
that the lack of support means that, in practice, both things convey the 
same, so the failure would apply even if you use <dfn>, or <em>, or 
<strong> or any other "content semantics" element. Or, more precisely, 
you would fail Conformance Requirement #4 due to "not using the 
technology in a way that is accessibility supported".


> The heart of the issue is that when the superscript element is used we are
> pretty sure the intention of the author was to make it a superscript.
> When CSS is used without markup -- a tool doesn't really know the
> intention of the author and thus can't make a valid decision on how to
> represent the information in an alternative format.

I'm not so sure of that... In my view the core of this thread is if HTMl 
elements are the only way to "programmatically determine" the semantics 
of the content. For example, RDF can convey much more semantics than 
HTML, but it is the lack of accessibility support what makes it unusable 
for accessibility.

But what if someone creates a User Agent that reads the RDF information 
in a meaningful way? What if we use @data- attributes to apply new 
meanings? What if we use @aria-label and other "non-visual" attributes? 
Do all these techniques fail SC 1.3.1 just because they do not use pure 
HTML elements? Even more, how can we reach conformance in a PDF that has 
almost no "content semantics" tags?

"Programmatically" means that a *program*, not a human,  can determine 
the relationship; of course the objective is that the program presents 
then the information in a meaningful way to the human, but theoretically 
it might be done even with CSS (although of course I'm not defending the 
use of CSS to convey information).

(As a side note: I use a lot the *asterisks* to mark emphasis -although 
my e-mail program represents it as "bold"; others use /slashes/ for that 
because it is usually represented as italics; both are ways of 
representing meanings without HTML tags, and they are probably better 
discoverable by a screen reader user)


 > People need to consider the different ways, formats, and
 > assistive technologies that users may be use and the
 > different types of people with disabilities that will consume
 > the content.

Exactly! <wink> But because people can use formats, we must consider the 
multiple ways that could be used to convey semantics apart from 
rudimentary HTML semantics.


> After spending so much time in this community I had thought
 > we had already addressed the need for people to consume
 > information differently -- but it sounds like this is
 > a continual effort that we must do to educate others.

Sure it is -and will be- a continual effort, but I see this discussion 
as a technical debate about what is required for "determinability" in a 
world full of meaning.

Regards,
Ramón.


[1] HTML5 - The em element
http://www.w3.org/TR/html5/text-level-semantics.html#the-em-element

Received on Saturday, 22 February 2014 20:38:12 UTC