RE: [WSG] Accessibility standards - for commercial consumption
I am not sure this is a good idea as there are several things people need to realise: - WCAG 2.0 has *not* been released yet. Success criteria such as parsed unambiguously and baseline may change significantly before then. I would not recommend completing any work until WCAG 2.0 has been released as a W3C Recommendation - Without spending a significant amount of time reading the documents we need to be careful not to misinterpret particular success criteria. For example, the parsed unambiguously success criteria specifically does *not* require you to validate your documents. - The fact that WCAG 2.0 is difficult to interpret is one of the least of its problems - even in plain English there are checkpoints missing (one Member of the Working Group has just lodged a formal complaint about the lack of cognitive disability related success criteria - a complaint that I have cosigned). Creating a plain English version of WCAG 2.0 will still be an incomplete set of guidelines. - Joe Clark is not talking about rewriting WCAG 2.0 in plain English - he is talking about rewriting the guidelines completely. Writing WCAG 2.0 in plain English will legitimise a document that still has serious problems. - This mailing list (mostly) contains people with a significant amount of experience in the web standards area and not so much in the accessibility area. The irony is that WCAG 2.0 practically ignores web standards entirely. - And finally, there is not yet any evidence that we (Australia) will ever need to refer to WCAG 2.0. HREOC - the governing body - may decide to keep referring to WCAG 1.0 instead of WCAG 2.0. They may also decide to write their own set of guidelines. Cheers, Gian -Original Message- From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Lachlan Hunt Sent: Saturday, 27 May 2006 10:03 PM To: wsg@webstandardsgroup.org Subject: Re: [WSG] Accessibility standards - for commercial consumption Nick Cowie wrote: > If it I get what Tony and Lachlan are proposing: > > As a community we take the individual WCAG 2 guidelines (either the > draft or > if and when the real ones) and translate them into language that could be > understood easily by web developers and provided simple check points. That's the general idea. > For example: > 4.1.1 Web units or authored components can be parsed unambiguously, > and the relationships in the resulting data structure are also > unambiguous. (Level 1) > > Translation: All browsers must interpret the structure of web pages the > same way Essentially, yes, but the criteria should be written with respect to the author, not the browser. e.g. Authors must write documents that can be parsed correctly by user agents and should not depend upon any error recovery techniques employed by user agents. > If that is the case where do I sign up. We'll get back to you about that. > My only concern is that all the work we do is not wasted if somebody else > comes out with a more authorative list (ie W3C) The W3C already has the understanding WCAG and techniques documents, which serve a similar purpose, but many authors are finding them difficult to understand. I don't know why, but I seem to be the only one who hasn't had too much difficulty getting through them (perhaps I spend too much time reading specs, so I'm used to the language :-)) > Should we also recommend baseline/s Yes, I think so. > Should we also suggest checkpoints beyond WCAG 2, for example to deal with > cognitive disabilites which WCAG appears to pay little attention to: > http://juicystudio.com/article/formal-objection-wcag-claiming-address-cognit ive-limitations.php That's possible, but we'd need to find some research that's been done in this area and figure out what authors can actually do to help with this. Before we go ahead with anything like this, there's a few issues we'd need to sort out. * Would this work be redundant, considering what the WCAG Samurai will be doing? * What exactly is the scope of the project? * Should we document general usability issues and techniques as well? * How does it differ from the Understanding WCAG 2.0 and Techniques for WCAG 2.0 documents? * What should we call the project? * How should we run the project? wiki? writeboard.com? mailing list? other? * Who should be the editor(s) and who has time to work on this? -- Lachlan Hunt http://lachy.id.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
RE: [WSG] Accessibility standards - for commercial consumption
HREOC's big stick is to taking the offending company/government department to court. How do you think a case would go with HREOC saying the offending web site is inaccessible because it did not validate it's documents as required by the HREOC guidelines and the web site is inaccessible. And the defendant saying it complied with the accepted international standard, the WCAG 2.0 by ensuring that all it's documents could be parsed unambiguously. No judge is going to be able to understand the issues and with a good lawyer arguing accepted international standard vs HREOC guidelines, HREOC will be left paying hefty court costs. --- HREOC is the governing body in this instance and has successfully fought and won an accessibility case in Australia. When I talk to clients they ask why they have to worry about accessibility and I refer directly to the DDA. In Australia, what the DDA recommends is what is legally required. I think you do not give either judges or lawyers enough credit for being able to differentiate between overseas law and Australian law. Gian
RE: [WSG] Accessibility standards - for commercial consumption
Hi I would like to say - just to clear any misconceptions - that I am not on the WCAG samurai list. Gian -Original Message- From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Lachlan Hunt Sent: Monday, 29 May 2006 10:28 PM To: wsg@webstandardsgroup.org Subject: Re: [WSG] Accessibility standards - for commercial consumption Tony Crockford wrote: > My suggestion and hope, was that this community could create a > document(s) that advised the web design community at large in a > pragmatic and specific way how to *implement* the guidelines. > ... > Of course the Academic approach dictates one generic document that > covers all technologies - easier to maintain and future-proof, and > that's the answer I suspect the WAI will give when asked to extend WCAG2 > to include real-life specific and pragmatic examples. Real life examples is supposedly what Techniques for WCAG 2.0 is all about, though it's not very good or complete. I think this illustrates what the web developer community should be focussing on. Rather than trying to translate a technical specification to make it readable by average joe developers, it would be more helpful to focus on the actual techniques that can be easily applied by others. Much like Position is Everything focuses on practical examples and explanations of CSS techniques and related issues, a site that does the same for accessibility would be very useful. There are several sites and resources that do offer accessibility tools and advice, such as Juicy Studio and WATS.ca, but when it comes to something that really walks a developer through accessibility from designing and building with modern, accessible techniques; coping with browser limitations, through to actually testing it with (and understanding how a disabled person uses) assistive technology, there really isn't all that much readily available. How many people here actually test their sites with a screen reader (or other assistive technology) regularly? One of the major problems is the price (JAWS, HPR and Windows-Eyes start from around $US800 or more), but even using a trial version, I expect most of us wouldn't really know where to begin. -- Lachlan Hunt http://lachy.id.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Navs at bottom of pages
I've noticed many people from this list stil put text-and-broken-pipe navs at the bottom of their pages. Is this still needed? Mostly the links at the bottom of the page are footer links (ie meta navigation) and therefore not provided in the normal navigation. It is rare for the main navigation to be replicated in the footer nowadays (although it was common five or six years ago). > I always thought the reason for it was to have a "text version" of the main graphics-with-out-alts-in-a-giant-table nav. Originally, yes, text links were provided because the original navigation was not accessible. I just want to make sure I'm not causing any problems by leaving them out. You won't be if your original navigation is accessible P.S. Am I also correctly remembering the broken pipes being used because of an early netscape bug regarding adjacent links? The use of broken pipes was mostly used (in my opinion, but then I'm an accessibility specialist ;) to address the Level AAA Checkpoint 10.5: Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links. Cheers, Gian *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Audio and Video
Hi Elaine The W3C Web Content Accessibility Guidelines, Version 1.0 have a number of Level A checkpoints when it comes to audio and video: Checkpoint 1.1: Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in element content). This includes: ... applets and programmatic objects, ... scripts, ... sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video. Checkpoint 1.3: Until user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation. Checkpoint 1.4: For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation. Essentially these three checkpoints mean that you need to: - provide an HTML transcript of the relevant file (Checkpoint 1.1) - provide captions for a video file (Checkpoint 1.3) - provide audio descriptions for a video file (Checkpoint 1.4) 1. Provide an HTML transcript of the file This is pretty easy for audio files: just transcribe what was said and who said it, along with any relevant background noise. With video files, you also need to transcribe any actions or events in the video that are relevant (eg. whether it is day or night, car accidents etc) 2. Provide captions for a video file Captions are used for people that are deaf and should therefore include not only what is said but also any noise that is relevant (eg. car backfiring, gunshot etc). Captions are *not* subtitles: subtitles interpret only spoken words. You can caption with MAGpie: http://ncam.wgbh.org/webaccess/magpie/magpie_help/install.html and they also have some handy captioning instructions: http://ncam.wgbh.org/webaccess/magpie/magpie_help/#captioning as does WebAIM: http://www.webaim.org/techniques/captions/magpie/version2/ The University of Wisconsin has some information on merging captions with a video file: http://streaming.wisconsin.edu/accessibility/magpie_tutorial/quicktime.html 3. Provide audio descriptions Audio descriptions are used by people that are blind and should therefore describe, in full, what is visually seen in the video. You can create audio descriptions with MAGpie and they also have instructions on how to do so: http://ncam.wgbh.org/webaccess/magpie/magpie_help/#audiodescription Joe Clark has also written some guidelines on providing audio descriptions: http://joeclark.org/access/description/ad-principles.html Skills for Access have some information on using MAGpie: http://www.skillsforaccess.org.uk/howto.php?id=135 and providing audio descriptions: http://www.skillsforaccess.org.uk/howto.php?id=104 I have some experience with HTML transcripts, captions and audio descriptions. I am more than happy to help further. Cheers, Gian Web Dandy Design wrote: Hi, I have a client who has asked for a website which will allow people to upload and download audio and video files and host streaming videos. Is there anything we need to put in place when the videos and audios are being made to make them accessible? What do I need to do to make the site as accessible as possible? Can anyone point me to any resources on this or does anyone have any expertise in this area and would like to get involved in the project? Thanks, Elaine http://www.webdandy.co.uk *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***begin:vcard fn:Gian Sampson-Wild n:Sampson-Wild;Gian org:Information Technology Services - Clayton Campus http://www.its.monash.edu.au/img/vcard/monlogo.gif"; ALT="Monash University" BORDER=0>;Web Resources Development title:User Interface Design Team version:2.1 end:vcard
