RE: Success criteria speak for themselves

I think a lot of this would be helped via some sort of custom ARIA attribute, but then maybe we would have to structure suggestions about how to use it effectively.

Jim



-----Original Message-----
From: Jonathan Avila [mailto:jon.avila@ssbbartgroup.com]
Sent: Sunday, February 23, 2014 8:23 PM
To: w3c-wai-ig@w3.org
Subject: RE: Success criteria speak for themselves

[Ramon wrote] "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).

Right expando attributes and CSS are also programmatically discernable --
so we have to figure out at what point programmatically discernable
becomes to inclusive.  Looking at the definition in WCAG doesn't clear up
this discussion -- it indicates AT and user agents can extract and present
the information.  Accessibility supported is the likely place to draw the
line -- but realistically just because AT can cull the information doesn't
mean it's accessible to users with low vision or cognitive impairments.
In some sense users could write CSS and other tools to assist but they
would likely not know how a site was providing the information.  It seems
like this is another good opportunity to expand ARIA and accessibility
APIs to convey flexible, perhaps custom information and ensure user agents
allow the broadest array of people to access this information without
plug-ins.  Given the struggle it's been to provide keyboard access to the
title attribute and keyboard access to headings and navigation views based
on HTML outlines, ARIA, or headings, I'm not sure what to expect.

Jonathan

-----Original Message-----
From: Ramón Corominas [mailto:listas@ramoncorominas.com]
Sent: Saturday, February 22, 2014 3:37 PM
To: Jonathan Avila
Cc: Wayne Dick; w3c-wai-ig@w3.org
Subject: 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


________________________________

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 Monday, 24 February 2014 18:25:05 UTC