Important summary: A primary purpose of What We're Working On - Accessibility Activities and Publications is to entice people to contribute to current accessibility work. It is not comprehensive nor Working Group focused.

On this page:

• Purpose/Goals/Objectives
• User Scenarios
• Notes and Open Issues
  • Scope
• Maintenance
• Notification of Updates

Primary:

• Entice people to contribute to current accessibility work at W3C (including existing participants in other areas and potential new W3C Members)
• Help avoid unnecessary duplication of work within W3C and outside of W3C
• Garner support for the work from W3C Members, potential funders, and others

Secondary:

• Provide an easy "landing page" for outreach about our current work

Tertiary:

• Encourage people to explore all the different WAI resources, find helpful stuff, and share it widely! (that is, share links on social media, Slack, etc.)

Primary:

• I'm an accessibility specialist and I would like to my company to join W3C so I can more directly participate in Working Groups. I use this information to put together a "case" for membership, pulling the things from this list that they would like to participate in.
• I've been wanting to contribute to W3C WAI work for a while, but I hadn't yet found where my skills and interests would fit well. With this page, I can see what's going on and connect with specific projects that are a good fit!

Secondary:

• I'm an [entrepreneur|graduate student] about to embark on a big project. In doing background research, I find that some of what I planned to do is already being done at W3C. I communicate with those involved at W3C so that my work is complementary to W3C work, and not overlapping.

Related scenario:

• I work as an accessibility specialist in a large company. I would like to know what specifications and additional resources are being created so I can follow that work and share them with my colleagues when they are published.
  [Note: We are not directly addressing this scenario because we are not listing all current work -- it would just be too long!]

• Organize it from user/reader perspective, not by WG-TF-CG structure.
• Consider how this relates to current News. Most likely this would be more interesting to more people than what we're currently doing with News.
  • Perhaps this should replace News to ease maintenance burden? Con: Need News Archive.
• Consider push newsletter sent to WAI-Announce list.
• Would be good to also update Participating in WAI (some user scenarios) (some done, more needed)

• Generally, all accessibility-related work at W3C, including things not directly under "WAI umbrella" like EPUB accessibility and timed text.
• What about work in Community Groups? Some active work we might want to include, yet much would get too long.

What's In and What's Out? This could get really long, which decreases it's usefulness. What should we not include, in order to keep it shorter? Ideas:

• Not include information that is not needed for goals and scenarios above. For example, not list some redesign work.
• Include just enough to entice interest, then provide link for more info.
• ... other ideas?... What We're Working On page -- what is not included right now and why

Should be fairly easy to be fairly lightweight.

• Anyone can submit an update, ideally via GitHub Pull Request. Or, ask someone in their group to submit the update.
• Updates will be reviewed by relevant Chair, Facilitator, and/or W3C Staff.
• We'll remind Chairs and Facilitators regularly to check that it is updated, via WAI-CC meeting or e-mail.
• Shawn (or other WAI Staff) will schedule time to publish updates regularly, at least once/week.

Note: If primary delivery is newsletter, maybe moot point?

How to support this use case: "I want to keep up-to-date on this stuff. I want to get a notification when this page is updated, and know which info was updated." It needs to be low-bandwidth for updaters — ideally something automatic. Ideas:

• [doing this one for now] Changelog at bottom of page with links to GitHub diff of updates? Con: A bit tedious for updater.
• [will send e-mail when significant updates] Send e-mail to WAI Announcements list when it's updated. Con: Manual process. If updated often, too much clutter on that mailing list.
• Add last updated to each section? Con: Maybe unnecessary clutter. And still doesn't notify them.
• They subscribe to GitHub notifications. Con: They'd get clutter of draft updates being refined.
• ... other ideas?...