RE: Accessibility requirement
WCAG 2.0 does have such a definition, and is in CR. It should be a W3C rec within a year, so seems like the appropriate doc to reference. As to your concerns related to WCAG itself, I'd be happy to follow up with you offline or on the WCAG list on those. Thanks, Cynthia -Original Message- From: Marcos Caceres [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2008 10:50 PM To: Arthur Barstow Cc: Cynthia Shelly; public-webapps Subject: Re: Accessibility requirement On Tue, Jul 29, 2008 at 4:15 AM, Arthur Barstow [EMAIL PROTECTED] wrote: 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?]. ]] I'm willing to point the Requirements doc to WCAG 1 or 2 if the group wants me to. I personally don't agree with a lot of the things in WCAG 1 or 2, but if it's the best we have so be it. It would be helpful if others with more experience in this area could provide some guidance on how to proceed. -- Marcos Caceres http://datadriven.com.au
Re: Accessibility requirement
On Tue, Jul 29, 2008 at 4:15 AM, Arthur Barstow [EMAIL PROTECTED] wrote: 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?]. ]] I'm willing to point the Requirements doc to WCAG 1 or 2 if the group wants me to. I personally don't agree with a lot of the things in WCAG 1 or 2, but if it's the best we have so be it. It would be helpful if others with more experience in this area could provide some guidance on how to proceed. -- Marcos Caceres http://datadriven.com.au
RE: Accessibility requirement
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
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
Re: Accessibility requirement
Hi Cynthia, On Fri, Jul 11, 2008 at 9:50 PM, Cynthia Shelly [EMAIL PROTECTED] wrote: Hi, I'm a member of wai-pf and wcag, and met some of you at the web apps face to face in redmond recently. I was reading through the widgets 1.0 requirements spec, and came across this accessibility requirement. Wondering why only should and may here, and not must? the reason we have should and may is to accommodate HTML, which is not as accessible as it could be. To have must would mean that HTML4.01 could not meet the requirement. R37. Language Accessibility A conforming specification must specify that the language used to declare the user interface of a widget be either HTMLhttp://www.w3.org/TR/widgets-reqs/#html or a language that is accessible at various levels: it should provide keyboard access to interactive graphical elements, and provide means to access the widget's functionality through an non-graphical UI. The declared interface may also be accessible to screen readers, allowing relevant sections of text and functionality to be accessed by non-visual means. Also, I noticed references to google and yahoo web gadgets documentation, and wondered if you'd seen the Windows Live Gadgets SDK [1]? We have, however the spec does not address the requirements of web widgets, such as iGoogle Gadgets or Windows Live Gadgets. Please see the Widgets Landscape document [1] for differences between web widgets and widgets as understood by the Working Group. Kind regards, Marcos [1] http://dev.w3.org/2006/waf/widgets-land/ -- Marcos Caceres http://datadriven.com.au
