Re: Accessibility requirement

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:marcosscaceres@gmail.com]
> 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
> <cyns@exchange.microsoft.com> 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
>

Received on Monday, 28 July 2008 18:16:35 UTC