Marcos, Cynthia,
Perhaps requirement #37 as currently written [1] is overly prescriptive.
For example, rather than trying to enumerate the sub-requirements for
the other language (i.e. the non-HTML language), there could just be
a reference to a spec/doc that defines the requirements for a
language to be accessible.
Also, the last sentence appears to be a statement about a Widget
instance (and not a requirement for a Widget UA) and hence should not
be normative.
Combining the above comments, I get:
[[
A conforming specification must specify that the language used to
declare the user interface of a widget be either HTML or a language
that is accessible as defined by [?SOME-WAI-RESOURCE?].
]]
-Regards, Art Barstow
[1] <http://www.w3.org/TR/2008/WD-widgets-reqs-20080625/#r37.->
On Jul 21, 2008, at 4:22 PM, ext Cynthia Shelly wrote:
There are some things that are difficult to make accessible using
only HTML, however most web content can be made accessible, even
without ARIA, by simply using the closest matching HTML Semantics
and triggering scripts from the onclick events of links. Those
things which can't be made accessible this way, I would argue,
should not get a pass on accessibility. They should be implemented
using ARIA or another technology that allows them to be made
accessible. So, to give some concrete examples
A flyout menu can be made accessible using HTML 4.01 and script by
carefully coding it as nested lists of links, with onclick handlers
on the links that open the sub-menus. Doing it this way instead of
using clickable or hoverable divs is a fairly easy change to make,
and can be done in a performant and usable way.
A spreadsheet, on the other hand, can't be modeled in HTML in a way
that will be either usable or performant. It requires ARIA (an
accessible different RIA technology other than HTML) in order to be
accessible. HTML 4.01 is not an appropriate technology choice for
this application.
If widgets were required to be accessible (MUST on both the
accessibility and screenreader requirements, rather than SHOULD and
MAY), both of the above could be built, but only the first could be
built in plain HTML 4.01. The second should not get a pass because
of a poor choice of technology for the application.
-----Original Message-----
From: Marcos Caceres [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2008 3:50 AM
To: Cynthia Shelly
Cc: public-webapps@w3.org
Subject: Re: Accessibility requirement
On Tue, Jul 15, 2008 at 12:10 AM, Cynthia Shelly
<[EMAIL PROTECTED]> wrote:
Interesting...
My experience has been that HTML 4.01 can be made accessible if it
is carefully coded. WCAG 2.0 has many >techniques for this,
including for scripted and styled content. While it is true than
many (possibly most) DHTML >applications have accessibility
issues, I do not believe that this is the fault of the standard so
much as the >authors. Do you have examples of things that cannot
be made accessible in HTML 4.01?
I agree in principle (though not with WCAG 2.0, but I don't want to
start a thread about WCAG 2.0 and accessibility).
I guess rather than writing out a list, I can simply cite the ARIA
spec [1] as it basically lists some of things that are missing for
accessibility in HTML4.01. Fortunately, ARIA has found a home in HTML5
but, from a standardization perspective, that's years away from
completion. Widgets, we assume/hope, we package HTML5 applications in
the future but we are standardizing, for better or for worsts, on
HTML4.01.
[1] http://www.w3.org/TR/wai-aria/
--
Marcos Caceres
http://datadriven.com.au
