-
Notifications
You must be signed in to change notification settings - Fork 11
Requirements Analysis: Industry specific guidance
Project: Industry specific guidance
As part of the WAI-Guide project, we want to produce guidance on how to implement accessibility in/with authoring tools, tailored to specific industries where authoring tools are made or used.
There are a lot of different kinds of authoring tools, used in a lot of different sectors. Specific guidance can help these sectors in more detail.
Intent from WAI-Guide project proposal:
Due to the broad scope of the types of authoring tools and the different industry sectors that they are used in, it is crucial to provide more tailored implementation guidance with clearly related examples. This builds on the existing accessibility requirements defined by ATAG and technical implementation guidance supporting the guidelines, with specific clarification related to the particular industry sector.
As this type of work is currently not chartered by any particular W3C Working Group, it may initially be incubated in a W3C Community Group in close coordination with W3C Accessibility Guidelines Working Group (AGWG) and W3C Education and Outreach Working Group (EWOG), and brought back into these formally chartered W3C working groups for further refinement and for final approval.
WAI-Guide staff will be the primary editors of these resources, with review and input from working group (and/or community group) participants as voluntary contribution. Each year of the WAI-Guide Project will focus on one industry sector, depending on the current needs and strategic priorities. The initial candidate sectors include education, digital publishing, and social media, given their relevance.
We can look at the target audience as roles and industries.
| Role | Impacts authoring tool accessibility how | Could benefit from/should see | Already available? | Impact |
|---|---|---|---|---|
| Front-end developer | Creates templates and components that are used in authoring tool (“pre-authored content”) | Info on how to build accessible components, copy-paste-able code examples. | Basics: yes (eg Tips for developing; advanced: no) | Large |
| Visual designer | Designs the interface, could design things that used authoring tool cannot implement accessibly | Info on how to design accessible components | Basics: yes (eg Tips for designing; advanced: no) | Small |
| Back-end developer / “integrator” | Integrates CMS and front-end, adds fields (custom fields or existing fields) where needed | How to build accessible widgets | Partly | Large |
| Content editor | Uses authoring tool to create content | Info on how to author accessibly | Not sure | Large |
| Accessibility expert / consultant | Advises company on accessibility strategy | Document making case for authoring tool accessibility argument | No | Potentially large, because they likely already know us |
| (Internal) accessibility champion | Tries to get the org to do more accessibility | Document making case for authoring tool accessibility argument | No | Potentially large, because they care |
| Procurer | Decides which authoring tool (vendor) to pick | Document explaining how authoring tools can accelerate accessibility | No | Large |
| Industry | Type of authoring tool | Roles |
|---|---|---|
| Education | LMS, CMS | Teacher |
| Social media | Social media | Social media expert / content producer |
| Healthcare | CMS, assignment creator, internal systems | Developer, product owner |
Industries as mentioned in proposal:
- education
- digital publishing / CMSes
- social media
Alternative title: With supportive Authoring Tools, you can tackle accessibility issues early before they go live
- Procurers
- Integrators
- Accessibility experts / evangelists
- Front-end developers / back-end developers
- Content editors
- S (all content)
- B
- CMS
- Authoring tool accessibility in context; there is a separate standard for authoring tools, see ATAG at a Glance
- Graphic of how CMS fits into process
- Examples of how authoring tools can help
- They can enforce certain practices
- Alternative text
- Names for tables, form groups, input fields
- They can run automated checks (“evaluations“)
- Spell checker
- Color contrast check
- …
- They can document accessibility
- They can enforce certain practices
- Call to action: how to ensure your authoring tool can do all of these good things? Add accessibility as a requirement when procuring a CMS/supplier.
Resource-specific requirements:
- Should contain colourful examples that a broad group of people can relate to (eg developer as well as product manager)
- Should not go into too much detail
- Should not be too long
A blog where WAI Staff interviews CMS makers about what they've done to accelerate accessibility from within their tools. Focused on not being marketing and avoids
- authoring tool vendors
- product managers
- M (requires continuous updates)
- A
- B
- CMS
- How WordPress leads the way with their document outline feature
- How Qontent leads the way by not allowing links to save if they only contain images without alt tags
- How Drupal leads the way implementing a
etc
- Should inspire authoring tool vendors to include accessibility
- Should showcase what the abstract “including accessibility” means with concrete examples
- Should cover a broad range of CMSes
- Should not be an advertisement or endorsement by W3C of an authoring tool
- developers
- designers
- Accessibility managers
- L (requires research, user testing, compatibility testing)
- A
- CMS
- explain how to design
- explain how to develop, including code examples
- Should be as vanilla as possible so that people can copy paste into their environment (framework/CMS/progamming language)
- Needs to form a good whole together with existing WAI Tutorials and other supplementary guidance
- product managers at CMS vendors
- S (mostly written content)
- A
- B
- CMS
- Explanation of how market will increasingly need accessible websites, including changing legislation
- Examples of how CM vendors can help their clients to reach those needs