Requirements and Changelog for How WAI Develops Accessibility Guidelines through the W3C Process:
Milestones and Opportunities to Contribute [Proces ("Process 101")
Changes in Version 2.0 Published 3 November 2008
- In "Working Draft" bullet, deleted "; for example, there were several WCAG 2.0 Working Drafts announced before Last Call"
- In "Last Call Working Draft" bullet, deleted "For example, see the WCAG 2.0 Last Call Announcement and Extention e-mail. (Note that after the Last Call comment period, it can take weeks or months for a Working Group to formally address all comments, document the resolutions, and make necessary changes.) If there are substantive changes, the technical report would go through another Last Call Working Draft before moving to the next stage."
- In "Proposed Recommendation" bullet, changed "The purpose of this stage is for W3C to gather endorsements of the stable technical report." to "At this stage, the report is submitted to the W3C Membership for endorsement."
Purpose, Goals, Objectives
- Educate people who are hearing about WCAG 2.0 and ATAG 2.0 Last Call
Working Drafts (LCWD)
- Limit misunderstandings and related "FUD" (fear, uncertainty, doubt)
- Answer current and potential questions, including:
- Has any public input has gone into the draft so far?
- Is LCWD the last stage? Is it the final version?
- What happens next (particularly with WCAG 2.0 comments)?
- [any others]?
- Address similar issues with other docs (e.g., from ERT WG and PFWG) and other stages (e.g., "Candidate Recommendation")
Note: Because of the large international impact of WCAG, misunderstandings about a document stage can cause significant concerns for those impacted by the final standard.
- Explain the process that a W3C "rec track doc" goes through from
Working Group drafts to W3C Recommendation
- Briefly describe the various stage of the W3C process
- Start from working group drafts (as opposed to earlier)
- Clearly equate "W3C Recommendations" with "Web Standards"
- Briefly mention other types of documents (e.g., Notes) provide supporting info (to help work with, implement), and can be updated more frequently
- Encourage people to participate in the various stages, as appropriate
- Perhaps explain that the earlier they comment the better
Target audience has little or no knowledge of W3C Process, and many don't know much about standards development or such.
- Primary audience:
- People following development of WCAG or ATAG or other WAI rec track docs
- Anyone who hears that a WAI doc is in a certain stage (e.g., LCWD) and is interested in what that means
- Full range of roles, including: web developers, managers, policy developers (government & internal), reporters, etc.
- Disability organizations and users with disabilities
Anyone interested in WAI recommendations
Anyone with a passing interest in W3C processes
Note that this document will not address all of the issues raised by the personas below.
- Web developer, Martina Prado – I want to know when WCAG 2.0 is going to be done and when I need to start working with it instead of WCAG 1.0. I don’t have time to review drafts and send comments. Just tell me when I need to do what with it. I don’t want to start working with it now if it is going to change a lot. However, I do want to be a little ahead of others in learning it. Also, I want to know a little about the process in case my clients ask me.
- Web Developer,
Andy Petroff – I heard some negative things about XYZAG 2.0
development, are they true? Here's
what I think about the process (Liam's e-mail <grin/>). [Andy
may or may not be interested in commenting, but it's important that he
know that he can.]
Note: Andy writes a well read blog on hard core, bleeding edge Web coding.
- Policy Maker, Chandra Weesaw – Our university is developing a Web accessibility policy, which we plan to have in place in a couple of months, and start requiring that new Web sites meet it by the start of the school year 2007. Should our policy point to WCAG 1.0 or WCAG 2.0?
- Reporter, Caryn-Ann Robinson or Kerry Roth – I'm writing an article on Web accessibility. WAI just announced XYZAG2.O last call working draft. What does that mean?
- Person with a disability user role, Mary Stone – I've been invited to speak at our campus Web developers group. I need a quick overview of what's coming up with developing Web accessibility standards.
- Disability organization – I'm the technical director of an international organization for people who are deaf. I need to keep up on accessibility standards around the world. I want to review the developing guidelines from WAI, see if we agree with what they are saying, and send in comments.
- Standards developer - Our international organization is developing standards. We want to coordinate with WCAG 2.0.
- Legislator, Brad Fletcher – [My country is writing a national Web accessibility policy.][Section 508 refresh is coming up.] I need to know the timing with WCAG 2.0.
- Web developer user role, Marc Blake – When do I need to bother with these new guidelines? [note: not at all interested in reviewing and commenting on drafts, or on any details of the process]
- Web Accessibility Specialist, William Travis – I would like to review XYZAG 2.0 and send in comments if I have any, but I don’t have much time so I want to WAIt until there's a complete version that's pretty much done.
- Manager user role, Jessica Pratner – We signed a legal agreement to make our Web site meet WCAG 1.0 by June 2007. How will 2.0 impact that? Why do you take so much time developing WCAG in big Working Groups and such a long, formal process? You could get it done a lot faster if a few people just sat in a room together and banged it out.
- Educator user role, Professor Xiaoping Zhang – We are including Web accessibility in our Web design courses. What should we be saying about the new guidelines? What about the process they go through at W3C?
Notes and Open Issues
- Size: 2 printed pages
- Be careful to keep short & simple, not try to address all related issues.
- [open] Where does it fit in WAI info architecture
&/or W3C Web site?
- Guidelines and Techniques? About WAI? Introducing Accessibility?
- link to from: Participating in WAI, above, others?
- "When should I start using WCAG 2.0?" we decided was better addressed in the Transitioning suite. Perhaps point to it there.
- Source: W3C Technical Report Development Process
- in Last Call list item: "it invites the community to review the document and confirm that the group has satisfied technical requirements and dependencies."
- graphic like http://www.w3.org/WAI/intro/equals.gif but with more
- note for future graphic alt: "Currently the alt text
is "diagram: [WAI Accessibility Guidelines] = [W3C Recommendations] = [Web Standards]" - please remove the "[" and "]" for the screen reader users (otherwise too verbose - JAWS for instance will announce each 'open square bracket" etc). And a question, does the screen reader user want/need to know this is a "diagram" as compared with any other type of image? - maybe Sylvie can give an opinion?
- note for future graphic alt: "Currently the alt text
- 20 Sept version (12) (with long alt text)
- 7 Sept version (10) (before edits for DanC's email)
- 5 Sept e-mail from DanC
- 1 Sept e-mail from Chaals
- 23 Aug main version, 21 Aug version with comments in process
- 21 Aug version
- 18 Aug EOWG telecon minutes, agenda
- 18 Aug e-mail from Helle
- 17 Aug e-mail from Natasha
- 16 Aug version
- 15 Aug version
- 14 Aug version
- 14 Aug EOW2 TF telecon minutes, agenda
- 11 Aug version
- graphic showing public & w3c member input
- 11 Aug EOWG telecon minutes, agenda
- 9 Aug e-mail from Helle
- 7 Aug version
- 7 Aug EOW2 TF telecon minutes, agenda
- 4 Aug version
- 4 Aug e-mail from Liam
- 4 Aug EOWG telecon minutes, agenda
- 2 Aug e-mail thread started by Alan C
- 31 July EOW2 TF telecon minutes, agenda
- 31 July & 1 August version & notes
- 7 July email: "Process 101" requirements for your review and comment
Note: See "References" section above for meeting minutes and e-mail comments.
- [open] CSS for positioning images left of OL #s, center .equals
18 August 2006 teleconference
- [done] slh/editor consider the move-up or consistent-info-per-stage
I took another pass at the document based on feedback from the 18 Aug teleconference. I also reviewed the Requirements above. Based on the requirements and after reviewing the previous versions and comments, I decided not to switch the order around again, and to leave the stages as the first focus, and commenting as the second point.
I did try integrating some more about commenting in the stages. A draft is at: http://www.w3.org/WAI/EO/Drafts/w3c-process-old9process.html However, I think this complicates the stages too much. Many people will want to know the basics of the stages, without the details of review and comment (per the personas above).
So instead, I significantly clarified commenting in a separate section, starting out with bold "You can comment on WAI documents at any time..."
- [done] slh take that image (CR) and play w/ it...
- [done] Intro: I tried editing the intro again, and decided to leave it as is. I know that first part isn't smooth; however, it says what i want it to say, and I'm therefore inclined to call it good enough for a first version.
- [done] title (brainstorms below)
- [done] 18 Aug e-mail from Helle, editor's reply
- [done] 17 Aug e-mail from Natasha, editor's reply
17 August 2006 (and beyond)
- [done] title brainstorms:
- "How WAI Develops Accessibility Guidelines with community input"
- The development of WAI recommendations through the W3C standards process
- Milestones Along the W3C Procses: Opportunities for Contributing to
WAI Accesisbility Standards
WAI Guidelines and the W3C Standards Development Process: Milestons and Opportunities
How WAI Guidelines Progress through the W3C Process
How WAI Guidelines are Developed through the W3C Process: Milesstones and Opportunities to Contribute to International Standards
[ Guidelines |OR| Documents ]
- [done] continue working on image(s)
- [done] change from getting involve in WAI to contributing to specific document
- [done] keep first paragraph, and expand first sentence, even stronger
- [done] tweaks to personas
- [done] consider adding that all comments have to be addressed & recorded (and thus how long it takes)
- [done] consider including "technical report"
- [done] largely go back to 7 Aug version, including put the link to the process after and listing types of docs
- [done] adjust the last bullet under specifics
- [done] 9
August e-mail from Helle
- [done] consider: Document stages to a W3C Recommendation should be moved up.
- [done] consider: In 2. Last Call Working Draft:… I would like to have a sentence about sending comments like in 1. Working Draft:… Comments received now are most easily addressed. Maybe saying that comments are less easily addressed but they can still be submitted.
- [done] in requirements: add brief other types of documents (e.g., Notes) provide supporting info (work with, implement), and can be updated more frequently
- [done] in requirements: add primary audience bullet disability organizations and users with disabilities
- [done] in requirements: add way to encourage broad participation, review, comment
- [done] in requirements: clearly equate "W3C Recommendations" with "Web Standards"
- [done] in requirements: make clear that all documents (not just WCAG ATAG)
- [done] in requirements: make clear that all stages (not just LCWD)
- [done] tone: try to make it warm, approachable (as opposed to stiff & formal ;)
- [note] editor removed "Encourage early implementation" as out of scope
- [done] shawn's notes from EOWG minutes: emphasize the broader review from different stakeholder groups, and how people can take an active role in commenting, find out about drafts to comment on, etc. what is current status? how do I comments? what if doc already complete (comments for next revision)? consider flipping around approach to be based on newbies & outsiders coming to it with questions.
- [done] 4 Aug e-mail from Liam
- [done] 2 Aug e-mail thread started by Alan C
- [done] title brainstorms:
- Introduction to W3C Process and WAI Guidelines
- WAI Guidelines in the W3C Process: A Brief Introduction
- WAI Guidelines in the W3C Standards Development Process
- WAI Standards in the W3C Process
- w3c WAI process in the development of web standards
- [done] ACTION, shawn: get updated info on what is already available (e.g., from other W3C presentations)
- [done - top generic, bottom WAI focused] Focus first on current & upcoming issues with WCAG & ATAG, or can also make more generic (e.g., for others in W3C to use)?
Version 10: "You can comment on documents at any time; however, the best time to comment on technical reports is when WAI announces Working Drafts for review. Please send any technical comments before or during the Last Call Working Draft review period. It may be difficult for a Working Group to make substantive changes later in the process."
Version 12: "The best time to comment on technical reports is when WAI announces Working Drafts for review. Please send your comments early in the process, when the Working Group can most effectively address them in the developing technical report. Technical comments sent after the Last Call review period have less weight, and a Working Group might not be able to make substantive changes late in the process. The W3C Process Document provides more information on Reviews and Review Responsibilities."
- Ideally, reviewers send any technilca comments on early Workin Drafts, the Last Call is the opporunity to review how all the comments were implemented, and there are few substantive commments on the Last Call Working Draft.
- Your comments can have the most impact on the technilca report when you send them on early Working Drafts.
- When you send comments on early Working Drafts, they can have the greatest impact on the technical report.
- Please send your technical comments on early Working Drafs. Technical comments sent after the Last Call review period may not ahve the same impact.
Last Call Working Draft
Version 10: "When a Working Group believes it has addressed all technical requirements, it announces a Last Call Working Draft. The main purpose of the Last Call is to provide a complete document for thorough community review. After the Last Call comment period, it can take weeks or months for a Working Group to formally address all comments,..."
Version 12: When a Working Group believes it has addressed all comments and technical requirements, it announces a Last Call and provides the complete document for community review. For example, see the WCAG 2.0 Last Call Announcement and Extention e-mail. After the Last Call comment period...
- When a Working Group believes it has addressed all comments and technical requirements, it announces a Last Call with the complete document for community review. For example, see the WCAG 2.0 Last Call Announcement and Extention e-mail. After the Last Call comment period...
- When a Working Group believes it has addressed all comments and technical requirements, it provides the complete document for community review with a Last Call announcement.
- The main purpose of the Last Call is to provide a complete document for
final community review.
[changed "thorough" to "final" does that work? it's not really final...]
- The Last Call Working Draft provides a complete document for reviewers
to confirm the disposition of their previous comments. If there are
additional technical comments during review period, it can take weeks or
months for a Working Group to formally address all comments,...
[doesn't fit well in the flow, since commenting is addressed in a separate section lower down and not up here. also, realistically, are there pretty much always technical comments at last call?]
- what I want to say in the introduction:
WAI develops Web accessibility guidelines to help make the Web accessible to people with disabilities. To do so, we bring together multiple interests from around the world, including industry, disability organizations, accessibility researchers, government, and others interested in Web accessibility to collaborate on developing solutions. WAI [strives] follows a process in order to do the best we can to:
- ensure broad community input
- encourage consensus development
- Making CR apply to Web site developers & Web tool
developers, ala ATAG & UAAG, thoughts [trying to avoid
- W3C encourages developers to use the technical report in their Web-related projects.
- W3C encourages Web developers to use the technical report in their projects.
- W3C encourages Web product developers to use the technical report in their projects.
- W3C encourages the community to use the technical report in their development projects.
- W3C encourages developers to use the technical report in their Web products.
- W3C encourages developers to follow the technical report in their projects and products.