Important note: This Wiki page is edited by participants of the EOWG. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Working Group participants, WAI, or W3C. It may also have some very useful information.

EOWG Participation Info

From Education & Outreach
Jump to: navigation, search

Welcome to the W3C Web Accessibility Initiative (WAI) Education and Outreach Working Group (EOWG)!

The Basics

Most EOWG information is available from the main wiki page:

The EOWG home page has some high-level information:

Work and agendas

E-mail Lists

The following e-mails lists are currently used by EOWG. All are publicly archived.

  • — main EOWG list - goes to all participants (and about 100 lurkers)
  • — for planning work in EOWG. goes to Co-Chairs and Staff (and anyone else crazy enough to subscribe). EOWG participants use this list when you want to bring work to the EO planning team and to all of EOWG.
  • — place to archive stuff without cluttering other lists. Editorial Teams folks should CC this list when they are communicating with their teams directly. (If you use a Project-specific list below, then just send to that list; don't need to also send to this list :-).
  • — purpose: for public and others to get messages to the WG on things that need edits -- for those who won't want to do it through GitHub. goes to chairs and staff (and anyone else crazy enough to subscribe)

Project Lists:

  • — for work on Roles and Responsibilities
  • — for work on Developing Web Accessibility Presentations and Training

Note: You can choose to have a separate list for a project — just ask Shawn.


EOWG meets by teleconference alternating:

  • Fridays 8:30am US Eastern Time for up to 2 hours

To find what time this is in your region, you can check the world clock meeting planner.

Upcoming Teleconference Schedule shows which days we are meeting.

The phone connection and IRC info is linked from the EOWG meetings wiki page.

Availability for telecons

Please indicate your Availability for Upcoming EOWG Teleconferences in the form at:
You can change your answers at any time. The link to this form is on the EOWG home page near the top under "EOWG questionnaires (WBS):" and also on the EOWG Meetings wiki page under "Work for this week", Every week.


We use IRC during the teleconference to take minutes, share links, indicate support or not for proposals, etc. You can join IRC through a web browser or IRC client:

  • Information on using W3C IRC from a browser is here: IRC
  • Most people download an IRC client
    To join the EOWG IRC:
    • Server Address:
    • Port: 6667, 6665, 21 (choose one)
    • Channel: #eo

IRC non-minute comments:

  • By default, what you type in IRC shows up in the minutes.
  • To type something that you do not want recorded in the minutes, preface it with:
    For example:
    /me apologizes for the construction noise in the background
    It will show up in IRC with an asterisk and will not be in the minutes:
    * shawn apologizes for the construction noise in the background

Lots more info: Zakim IRC Bot

Code of Conduct

EOWG is covered by the W3C Code of Ethics and Professional Conduct



  • Provide specific, clear, succinct comments that are:
    • quickly understandable to all EOWG participants
    • easily action-able by the editors
  • Usually include proposed re-wording and rationale for it.
  • Ideally through GitHub fork, edit, pull requests:
    1. Fork and make the suggested change
    2. In the comment area,
      • Put a short description of the change (e.g., "introduction copyedits") in the box replacing "Update". Preface it with the comment level (below)
      • Put the rationale in the box replacing "Add an optional extended description..."
    3. Submit pull request
  • Usually do separate Pull Requests or Issues for each comment or suggestion. (Typos and other corrections can go in a single pull request.)
  • If in GitHub issue, survey, or e-mail, make sure to include the location of text you're commenting on, ideally with a link to it, and indicate the level. Comment format suggestion:
    • level: (low, med, high for draft reviews)
    • location: (such as: "page: Image Maps. under Introduction heading, third paragraph")
    • current wording:
    • suggested revision:
    • rationale:

Comment Levels

For draft reviews:

  • (low)
  • (med)
  • (high)

For approval to publish reviews:

  • [ED-low] = Editors' Discretion, low importance
  • [ED-med] = Editors' Discretion, medium importance
  • [!!] = High importance - must address (not necessarily must make the change, but must work it out to the commenter's satisfaction, which sometimes means additional EOWG meeting discussion)

Review Stages and Levels

Stages: Resources are typically reviewed by EOWG in the following stages of development:

  1. Rough concept draft (or rough wireframe for tool) — Review for overall content and general design. Do not bother with word-smithing or copy-editing or design nit-picks.
  2. In-progress drafts — Usually there will be specific review questions on certain sections or issues.
  3. Complete draft — Review for things like: Are all points covered - is anything missing? Is there anything in there that shouldn't be? Word-smithing suggestions usually welcome. Try to catch all significant issues at this stage. (if you bring up big issues later, it will be annoying :-)
  4. Thorough review! — Review everything at all levels, including copy-editing. This is the pre-publication review, our internal "last call".
    • Any changes after the Thorough Review will be documented so participants can review just those changes and don't have to re-review the whole resource.
  5. Approval to publish — Usually there shouldn't be any more comments at this stage, it's just the formal sign-off.

Sometimes Task Forces or small groups, rather than all of EOWG, do most of the in-progress draft reviews.


  • High-level - Comment on organization, structure, flow, tone, approach, meeting audience needs, overall content, etc. Do not bother with word-smithing or copy-editing or design nit-picks.
  • Detailed - Hopefully no high-level comments are needed at this point. Now is the time for detailed comments on specific content, including wording.
  • Show-stoppers - The Editor thinks the resource is ready to publish, and/or we are trying to meet a specific publication date. Only important issues should be raised as show-stoppers. Optional comments are welcome, marked as "editor's discretion" or "future enhancement".

Process for Minor Changes

For any significant changes, we use a survey for EOWG to approve changes. They are usually open at least 12 days.

For minor copy edits, corrections, and non-substantive changes, we use a lighter process to get things completed more quickly. The chairs and staff contact will determine what can fall under this process for minor changes.

  • Document editors, EOWG chairs, and staff contact approve changes. Changes are published.
  • EOWG is notified of changes and opportunity to review. Usually this will be listed in Work for the Week. (Optionally it can be via e-mail to the main EOWG list &/or in a weekly survey.)

Note that EOWG still reviews all changes to EOWG Resources. The only difference is whether the review is before or after the changes are posted.

OLD Archived Info

Editorial Teams

EOWG is trying an approach where a specific resource will be worked on first in smaller Editing Teams. We hope this will let individuals focus more attention on specific resources that they are particularly interested in, and help get more resources developed and revised more efficiently.

The expectation is that minor issues can be worked out in the Teams, allowing all of EOWG to focus on bigger issues. Resources brought to all of EOWG will already have been worked through by the Teams and will have clearly defined issues to address.

As a reminder, it is important that for formal EOWG deliverables we:

  • ensure that they reflect the perspectives and contributions of multiple different stakeholders in a wide range of environments (large industry, small consulting, developers, trainers, proj management, policy, geographic, disabilities, etc., etc., etc.)
  • develop consensus among WG participants particularly, and also commenters
  • maintain high quality


  • If you want to change your resource team assignments, e-mail
  • Editorial Team participants - commit to reviewing carefully and commenting "in a timely manner".
  • Editorial Team [monitors] - would like to be included in review opportunities, yet don't commit to completing all reviews.

Teams Approach

The overarching approach is that the Teams will:

  • Try to represent a wide range of perspectives (not just their own), and actively solicit input outside of their areas, such as international perspectives.
  • Make initial decisions when there is clear consensus within the Editorial Teams. Communicate the issues where they had some questions or specifically want additional perspectives.
  • For issues where there is not clear agreement within the Teams, the Editors should present the issue for broader input from EOWG (and WAI IG and others as appropriate) — with a brief summary and pointer to background discussions (in GitHub, etc.).

Process for revising existing resources:

  1. Editors review resource and provide summary of significant suggested changes – can be quick bullets – and any questions or issues at this point, especially that impact overall approach.
  2. Discuss with EO Planning Team and see if need EOWG to review suggested changes and big issues.
    (Brent provided example of helpful initial feedback in 21 July teleconference)
  3. Editors draft changes.
    Editorial Team reviews draft.
    As needed, bring issues to EOWG (per next section)
    Iterate as needed — number of iterations needed usually depends on extent of revisions, sensitivity of topic, etc.
  4. When Editorial Teams thinks it's ready, Editors bring to EO Planning Team to schedule EOWG full review. Usually this will be a "Thorough Review" (aka last call). Editorial teams provide:
    • Explanation of any issues for input from EOWG
    • List of changes &/or diff version
Minimum for Relaunch, Log for Later

Important: We want to do minimal work to update and clean up resources for the redesigned website soon. We have planned time later to make revisions that take more time to develop, review, and get consensus on. Please do record ideas for later revision, e.g., in GitHub with Labels and Milestones — e.g, has label "future enhancement" and milestone "Post-Launch Enhancement".

When and how to bring what to EOWG

We encourage Teams to bring questions, issues, and drafts to EO Planning Team and then to all of EOWG whenever it will be useful to get broad input.

  • Issues can be brought to EOWG (after coordination with EO Planning) individually, as a batch, or along with a draft for review.
  • If a Team needs EOWG input on an issue (such as overall requirements, structure, approach, content outline, etc.) before moving forward with the resource — or if EOWG input could substantially change the work, they should bring it to EOWG soon.
  • If several smaller issues are accumulating, it would probably be good to bring them to EOWG to avoid lots and lots for EOWG to process at once.
  • @@ complete draft for review @@

How to bring issues and drafts to EOWG: It is most efficient to have specific issues/questions for EOWG.


Optionally, you can have a separate mailing list for your Editorial Teams -- just ask Shawn to set it up.

If you don't have a separate list, CC e-mail communications among your Team participants to That will:

  • Fulfill EOWG's mandate to conduct work in public space
  • Let us go back and look up or reference info if needed
  • Help Chairs and Staff keep on top of things and see if there are ways they can help

You do not need to replicate GitHub issues to any mailing list; GitHub is sufficient public archive.


Editing Approach

For most documents:

  • Simplify & Tersify — Make content simple and brief. Cut words. Cut Sentences.
  • Bullets & Graphics — Break up passages into bullets when appropriate. Suggest graphics.
  • Front-loaded Action — Use active voice, and action statements.

For spelling, punctuation, editorial style tips, etc., see WAI Style Guide (which includes language tools and Edit Examples)

Comments and changes

  • Editors should track, manage, and respond to issues in GitHub and comments in surveys.
  • Generally, Editors can close issues, and should invite the commenter to re-open it if they are not satisfied with the resolution.
  • Editors should usually provide a list of substantial changes &/or issues. In later stages, it is usually helpful to provide a diff showing changes.

To provide a diff using rawgit:

  • @@