Skip to content

Requirements Analysis: Authoring Tools List

Jump to bottom
Hidde de Vries edited this page Aug 2, 2019 · 18 revisions

Requirements analysis for Authoring Tools List.

Approach

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.

Terminology

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.

Purpose

Page

  • Introduce people to authoring tool accessibility
  • List features that authoring tools can be compared by
  • Point people to the authoring tools list

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

Target audience

  • designers
  • developers
  • procurers
  • content editors
  • accessibility auditors
  • QA testers
  • project managers

Use cases

  • 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

Intended benefits

Page

  • Addresses wider audience than the ATAG specification
  • Provides context to list

List

  • Makes it easier for users to find AT that meets their requirements
  • Incentivises vendors to make AT more accessible

Features

List

  • 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 self-vetted by the submitter, vetting questions are designed to yield useful output
  • Each tool listing has clear shortcut to report it (also reinforces that content is user submitted)

Risks

List

  • 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

Vetting questions

Each can be answered as YES / NO / NOT SURE / NOT APPLICABLE, so that we could display these answers and use them for filters.

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?

“Add a tool” process

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):

  1. Submitter goes to “Add a tool” page
  2. 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)
  3. If required fields are answered, the answers are saved in JSON format
  4. (Ideally) Pull Request is created with this JSON file, this could already generate a deploy preview
  5. JSON is reviewed by W3C Staff
  6. W3C Staff merges PR and adds file in CVS

Mockups

In progress

Clone this wiki locally