-
Notifications
You must be signed in to change notification settings - Fork 11
Requirements Analysis: Authoring Tools List
Hidde de Vries edited this page Dec 10, 2019
·
18 revisions
Requirements analysis for Authoring Tools List.
We believe content management systems and other authoring tools can make a big difference in making the web more accessible, so want to promote adoption of the Authoring Tools Acccessbibility Guidelines (ATAG). To help organisations find authoring tools that support accessibility and/or ATAG features, we will create a list of them. We ask vendors to submit their authoring tools to the list themselves, answering questions about their tool and about their tool's accessibility.
| What | When |
|---|---|
| Front-end/prototype complete | End of October 2019 |
| Received/processed feedback from vendors | Mid November 2019 |
| Functionality complete | Mid December 2019 |
Project stalled in November
The “AT List” project will deliver two parts:
- A page on w3.org/WAI that explains what to consider if you want to select an authoring tool, similar to Selecting Web Accessibility Evaluation Tools
- A list of authoring tools: this is an application where we bring together people who want to use authoring tools and (vendors of) authoring tools. Users can find authoring tools based on filters, vendors (or others) can submit authoring tools by self-classifying them in the filter criteria.
In this requirements analysis, I will use these words as follows:
- Authoring Tools: tools that create web content, including CMSes (see Defining Authoring Tools)
- Users: people who need to find authoring tools (for themselves, for their clients or their employers)
- Vendors: people or companies who make authoring tools
- Submitters: people who submit authoring tools, they could be vendors, but don't have to be.
- Introduce people to authoring tool accessibility
- List features that authoring tools can be compared by
- Point people to the authoring tools list
- Help people find authoring tools by accessibility-specific criteria
- Encourage accessible authoring tools by showing the world what the accessible authoring tool landscape looks like
- designers
- developers
- procurers
- content editors
- accessibility auditors
- QA testers
- project managers
- Someone needs to choose a CMS for their organisation or client
- Someone wants to learn about which features can improve authoring tool accessibility
- This includes everyone from people creating new features to management
- Someone produces authoring tools and want to compare their product to competition products
- Someone wants to host his/her web site but wants to know if the web host provider makes available a website builder which provides accessibility features
- An educational institution which wants to set up online courses which are accessible
- Addresses wider audience than the ATAG specification
- Provides context to list
- Makes it easier for users to find AT that meets their requirements
- Incentivises vendors to make AT more accessible
- People can select by type of authoring tool: CMS, WYSIWYG editor, social medium, etc. Each may have different criteria attached to it.
- Authoring Tool submissions are submitted by the vendor, accessibility features are designed to be easy to say 'yes'/'no'/'partially' to (for the submitter) and easy to use as filter (for the end user)
- Each tool listing has clear shortcut to report it (also reinforces that content is user submitted)
- This could be seen as W3C endorsing specific Authoring Tools.
- Mitigation: provide both short and long disclaimer that we do not endorse any tools, we only provide a framework in which users and vendors can find each other. Also embed “Report issue with this tool” functionality with each displayed tool to reinforce that content can be inadequate
- Not enough Authoring Tools to select from.
- Mitigation: engage with AT community early and often
Each is both easy to answer (for a submitter) and easy to use as a filter (for the end user):
-
YES
-
NO
-
PARTIALLY
Triggers comment field -
NOT SURE / NOT APPLICABLE
Means this criterion is not going to be displayed / taken out of the equation.
so that we could display these answers and use them for filters.
Users can browse authoring tools by the answers to these questions.
Some intitial ideas for questions, based on specific ATAG sucess criteria:
- Are all interactive controls (including links, buttons, forms) usable with only a keyboard?
- Are there no time limits, or if they exist, can they be turned off?
- Is there are way to help authors avoid flashing content?
- Can content be navigated by structure (ie headings, elements, document outline)?
- Can content be searched?
- Is previewed content accessible?
- Is content automatically spell-checked?
- Can content changes be undone?
- Are accessibility features described?
- Are accessibility features documented?
- When users copy and paste content within your tool, is accessibility information preserved? (B1.2.2)?
- Does the tool allow setting accessiblity properties needed for WCAG compliance (B2.2.2)?
- Can alternative text be edited (B2.3.1)?
- Are WCAG-compliant templates available (B2.4.1)?
- Are alternative texts for images enforced (B3.1.1)?
- Are video alternatives (captions, audio descriptions) enforced (B3.1.1)?
- Are accessibility features on by default?
To be usable as filters, this maps ATAG success criteria to 4-5 word descriptions, separated between editing experience (part A of ATAG) and output (part B of ATAG).
| SC | Short name | Full name |
|---|---|---|
| A.1.1.1 | Complies with WCAG | Web-Based Accessible (WCAG): If the authoring tool contains web-based user interfaces, then those web-based user interfaces meet the WCAG 2.0 success criteria. (Level A-AAA) |
| A.1.2.1 | Meets platform-specific accessibility guidelines | Accessibility Guidelines: If the authoring tool contains non-web-based user interfaces, then those non-web-based user interfaces follow user interface accessibility guidelines for the platform. (Level A) |
| A.1.2.2 | Integrates with platform-specific accessibility services | Platform Accessibility Services: If the authoring tool contains non-web-based user interfaces, then those non-web-based user interfaces expose accessibility information through platform accessibility services. |
| A.2.1.1 | Text alternatives available | Text Alternatives for Rendered Non-Text Content: If an editing-view renders non-text content, then any programmatically associated text alternatives for the non-text content can be programmatically determined. (Level A) |
| A.2.1.2 | Alternatives for audio/video rendered | Alternatives for Rendered Time-Based Media: If an editing-view renders time-based media, then at least one of the following is true: (a) Option to Render: The authoring tool provides the option to render alternatives for the time-based media; or (b) User Agent Option: Authors have the option to preview the time-based media in a user agent that is able to render the alternatives. |
| A.2.2.1 | Status updates conveyed to Assistive Technology | Editing-View Status Indicators: If an editing-view adds status indicators to the content being edited, then the information being conveyed by the status indicators can be programmatically determined. (Level A) |
| A.2.2.2 | Text formatting conveyed to Assistive Technology | Access to Rendered Text Properties: If an editing-view renders any text formatting properties that authors can also edit using the editing-view, then the properties can be programmatically determined. (Level AA) |
| A.3.1.1 | Works with keyboard | Keyboard Access (Minimum): All functionality of the authoring tool is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A) |
| A.3.1.2 | No keyboard traps | No Keyboard Traps: If keyboard focus can be moved to a component using a keyboard interface, then focus can be moved away from that component using only a keyboard interface. If it requires more than unmodified arrow or tab keys or other standard exit methods, authors are advised of the method for moving focus away. (Level A) |
| A.3.1.3 | Keyboard access efficient | Efficient Keyboard Access: The authoring tool user interface includes mechanisms to make keyboard access more efficient than sequential keyboard access. (Level AA) |
etc…
This approach does not directly use ATAG criteria, but it creates a new list of criteria, each of which can be traced back to one or more ATAG success criteria.
- Works with keyboard
- Buttons have names
- No time limits
- Flashing content optional
- Content text search provided
- Previews accessible
- Acccessibility information preserved
- Content spell-checked
- Accessibility documentation provided
- Accessible templates available
This is what my ideal process would probably look like (optimised for (1) ease of maintenance and (2) similarity with other lists that WAI offers):
- Submitter goes to “Add a tool” page
- They specify their tool (name, type of AT, description, etc) and answer a set of predefined questions (the more questions answered, the better it can be found)
- If required fields are answered, the answers are saved in JSON format
- (Ideally) Pull Request is created with this JSON file, this could already generate a deploy preview
- JSON is reviewed by W3C Staff
- W3C Staff merges PR and adds file in CVS
As a user, I want to…
- Find out new tools have loaded
- Find out something went wrong in loading tools
- Fill in information:
- all information) related to my tool
- my information:
- name (required)
- email (required)
- comment
- Find out about the status of my submission
- Prove that I am the vendor of the tool
- Find link to file in git (GitHub)
- Submit pull request that changes this file (this story is outside our ecosystem; people can do it because we use git and it is public)
- Read disclaimer to understand W3C's stance regarding these tools
- See who made this tool (working group, EC)
- See details (all information per tool)
- Get permanent URL to tool
- Find link to file issue in GitHub
- Use predefined GitHub issue template to explain my issue
- name (required)
- vendor (required)
- website (required)
- description
- license (required)
- date submitted (required)
- date released
- version
- cost
- accessibility statement
- conforms / does not conform checkboxes for each of the criteria