Back to EOWG Wiki home page | Back to quickref home page

Help developers find WCAG2.0 accessibility information like techniques and tutorials more easily by updating the “How to Meet WCAG 2.0” document („quickref“) with an easier to use interface and useful functionality. This interface shows an overview of WCAG 2.0 by default and allows the user to explore details. It will also make it possible to send out links to the document that reflect the filters that are set. This functionality will help teams to collaborate their accessibility efforts. The new document will also automatically save the current status when leaving the page and provide a checklist mechanism that helps users to keep track of their changes.

---

(based on this draft EO document)

Current Document: How to Meet WCAG 2.0

Redesign Mock-up: (Mockup) How to Meet WCAG 2.0

The amount of information provided by WCAG 2.0 Supporting Documents are perceived as being too complicated by many. There is also a vast amount of supporting documents (Understanding, Techniques and EO material, like the “How people with disabilities use the web” or the tutorials) and most people have trouble to find the information they need. Some things that could help with this:

• Access Hub: Provide authors with (pointers to) information they may need.
• Improve the experience of quickly filtering and viewing WCAG 2.0 related resources related to a author’s specific needs.
• Let users drill down to specific information from an easy to understand high-level overview
• Show links to other relevant documents such as the tutorials, eval tools list or how pwd use the web.
• Help authors to explore and find out the information that is relevant for them.

What are the tasks the current version is doing well:

• It gives quick access to the techniques (sufficient and advisory) and failures, ordered by success criteria.
• It allows techniques to be filtered by different criteria, like technology.
• It shows how techniques can work together to meet a certain scenario. (For example for Success Criterion 1.1.1 different situations are defined. Then techniques are listed that show how to handle that situation.)

• Content Authors (Designers/Developers/…) generally looking for … [AWK: What level of knowledge?]
  • instances of successful examples, like techniques (WCAG WG) or tutorials (EOWG)
  • easy implementable solutions (WAI-DEV project: Gallery of Accessible Web Components)
  • interoperability information (from WAI-ACT: Accessibility Support Database) [AWK: I can see building this in a way to allow this to be used in the future but don't think that the ASD is quite ready as a resource, is it?]
  • which success criteria to check
  • advice on how to use HTML elements
  • advice on how to use CSS properties

• Evaluators generally looking for …
  • techniques that they can recommend to authors
  • instances of failures
  • tools to test for above (from WAI-ACT: Evaluation Tools List)
  • advice on which techniques to prefer (Out of scope.)
  • Need: Find out more detailed needs.
• MC: I think policy makers (government or organization) are a primary audience. They need to have a good enough understanding of how WCAG works to make realistic policy, without getting drowned in details. In particular they need to understand sufficiency of techniques, different content technologies, allowing non-documented techniques...

Audiences that may encounter the page and should be lead to a place that is more suitable to them.

• People new to WCAG 2.0 generally looking for …
  • guidance on the basic higher-level accessibility principles
  • quick take-aways
• Browser Implementers
• Project Managers
• Accessibility Organizations

Tasks that should be in Version 1.0 of the tool.

1. I want to see a combination of techniques that I can use to meet a success criterion [basically what the current quickref does] — EE

2. I have a fairly basic website with a form and want to see information relevant for me and get rid of other info.

   • AWK: I love this idea, to be able to check off images, text, forms, and deselect video and tables to get a more customised set.
   • [JOC] Also a strong +1 from me. I like the idea of a 'relevant content based approached' that fits in with developers workflow. There could be 'filtering by content types' such as images, forms etc, and not such technology.
   • EE: Thinking about it, probably that could as well be a tag cloud or an autocomplete. (else images need to be selected if someone types “alt text”, “text alternative“, “alt”, “longdesc” ect.)

3. I want to skim through the high-level requirements for WCAG 2.0, and then drill down to more details for specific points that I need more information on.

4. AWK: I want to see ONLY techniques for SVG or other technologies (not general techs) and see a table showing coverage of SC vs. technology.

#### Secondary Tasks

Tasks that should be in Version 1.0 of the tool but could be behind a switch, as secondary information.

1. I want to get an overview of available WCAG 2.0 support material. (EE)
2. I’d like to print out a simple checklist with all information. [AWK: what does "all" mean here? EE: All information on the page.]

#### Nice-to-have Tasks

Tasks that don’t need to be in Version 1.

1. I want to see what and how techniques have recently changed.

   • In nice-2-have as this could be a lot of additional work. It would be good to explore possibilities. — EE

2. I want to know which techniques especially apply to my target group (for example older people) so I can prioritize changes along those lines.

3. I have a complex website and would like to ensure accessibility by using an interactive checklist where I can check off the things we've already done, and update it as we meet other SC.

   • AWK: this seems a higher order of magnitude of difficulty. Maybe I'm not envisioning the same thing you're describing...

Tasks that we don’t want to implement.

1. I want to access a high-level overview about what WCAG Web Accessibility is all about.

   • EE: May be covered by WCAG at a Glance?
     • [AWK: Thought that this was excluded above??] [JOC] Yes, I think this is out of scope.

2. I need to manage/buy a web project and would like to learn about difference between Level A and Level AA, and impact on a project. [might fall out of scope to have such a high level view] [JOC] Yes, I think this could be out of scope.

Note: This is a list of possible features and approaches, the main question is: How much do we want to guide what the user is seeing?

• Using a news-like teaser format to target different audiences
• Possibility to add teasers that contain tagged resources
  • Example: AJAX collects resources tagged with XMLHTTPRequest, aria-live and JavaScript

• Default view is a caniuse-like web page with mainly a search field
• Users can perform a fuzzy search and get results to all possible WAI resources back.
• The search term is attached to the URL which makes the search result easily shareable.
• Users can print that view.

• Default view is minimum info, probably just guidelines, then user can expand specific nodes. [down to what level?]
• Users can save that customized expanded view.
• Users can get a link to that view. eg, to email to colleagues. [MC: that could lead to super duper long URIs if various things are expanded and collapsed unless a URI shortening mechanism is included]
• Users can print that view. [MC: print view optimized for print, e.g,. without all the navigation cruft]
• Users can export that view to other formats (eg HTML, word processing, spreadsheet). [see also checklist below]
• notes: [http://www.w3.org/WAI/EO/Drafts/quick-ref/beta1-1 draft playing around with that a bit](http://www.w3.org/WAI/EO/Drafts/quick-ref/beta1-1 draft playing around with that a bit "wikilink") [see also Notes on Expand-Collapse Functionality for WAI Resources]

• Users can create checklist with a column for Status and a column for Notes (e.g., for things like which techniques were used).
• Users can save customized checklist format.
• Users can get a link to that checklist. eg, to email to colleagues.
• Users can print that checklist.
• Users can export that checklist to other formats (eg HTML, word processing, spreadsheet).
• Users can include a technique used that is not in WCAG. (i.e., instead of just checking which existing WCAG technique is used, they can add their own technique)
• [@@ default example checklists, e.g., for mom & pop site vs for e-commerce site... customization wizard]
• note: caution about encouraging the checklist approach (more complex than yes, no, maybe - e.g., need to list techniques used)

• Users can select to show simple informative notes on basically what each guideline and success criteria means, often with a common example. (so they grok the basic meaning -- then be able to drill down to the normative wording and technical details)
• [note: we don't currently have that content, but have been working on it in various places]

• Users can filter or highlight all the success criteria and techniques that particularly relate to a specific functionality or task, such as: designing a form, coding a table, etc.

• Users can filter or highlight all the success criteria and techniques that particularly relate to a specific role, such as: basic content authors, visual designers, programmers, evaluators
• note: some work already done on this
• note: I don’t know if we can do this in a useful manner with the current data set. --Eric Eggert ([talk](User talk:Eeggert "wikilink")) 09:32, 23 October 2014 (UTC)

• Users can select to have highlighted all the success criteria and techniques that particularly relate to one of more of:
  • general usability
  • older users
  • design for mobile devices
  • internationalization
  • business case aspects
  • ...
• Users can save, link to, print, and export this view as in above items.

• Consider adding Read How PWDs Use the Web and Involving Users in Web Projects for Better, Easier Accessibility in the Introduction and as first items in the checklist :)
  • I think those items are really important (see this Twitter discussion), many web developers have no idea of what assistive technology is capable of. --Eric Eggert ([talk](User talk:Eeggert "wikilink")) 09:32, 23 October 2014 (UTC)
  • MC: this is important information but front-loading it at the top of a checklist just means more cruft to wade through before getting to the stuff you're there for. Need to implement in a way that people can easily find it if they want it but not be forced to deal with it if they don't.

• If we want that, we should decide it very early, so we can have the technical foundations in place. --Eric Eggert ([talk](User talk:Eeggert "wikilink")) 09:32, 23 October 2014 (UTC)

How did others approach this. Probably we can learn something.

• http://www.3pha.com/wcag2/ - material from our Quick Ref re-presented with all SC on one page and details in popup dialog box like
• http://www.oneguidelineaday.com/
• http://www.accessiq.org/web-accessibility-wizard?keywords=images&items_per_page=20
• http://wja.no/wcag/
• http://diagramcenter.org/54-9-tips-for-creating-accessible-epub-3-files.html
• http://www.w3.org/2009/cheatsheet/
• http://webaim.org/standards/wcag/checklist

• Web Platform Docs (accessibility.webplatform.org could lure developers)
• Validator could send people to this platform for accessibility relevant errors/warnings

• When linking to resources, we should give users a possibility to get back to where they come from (using frames??) --Eric Eggert ([talk](User talk:Eeggert "wikilink")) 20:10, 1 December 2014 (UTC)
  • MC: This is a general problem in Web design and I hesitate to try to solve it. Common approaches include opening links in new windows, or the frames approach, but those bring other problems with them. If implementing something like this, should give the user the choice or whether they just want a simple "I'll find my own way back thank you" design.
    • I agree. --Eric Eggert ([talk](User talk:Eeggert "wikilink")) 16:30, 6 January 2015 (UTC)

Making the tool part of the WCAG build thus making it dependent on the format of WCAG XML files. If the format changes (and the techniques format may very likely change) the tool would need to interpret that information correctly. If other resources need to get added that may need to be done through the WCAG WG and the WCAG XML format.

Another approach is to make the tool self-dependent and require from all resources an XML (JSON?) file with the information that should be displayed. This would make it much easier to build the tool, resources would be referenced from the tool. Those content files would be editable by the groups (each group would edit its own resources) and the tool would automatically reflect changes.

Example: The tool has a list with the following resource files:

• path/to/WCAG/techniques.xml
• path/to/EO/tutorials.xml

When tutorials are updated, the tutorial.xml is updated as well (hopefully automatically).

• OPEN ISSUE: One tool pulls in info from Understanding & Techniques (rather than send you out to another document/page)?
• OPEN ISSUE: Maybe choose views by role, e.g., policy versus developer versus evaluator?
• [??Context??] NOTE: Can @@Liam's idea of nav in the understanding, techniques, etc. -- breadcrumb knowing where they came from?
• @@ relationship to WCAG 2 at a Glance ? maybe that's an alternative view for newbies, notes.
• @@ for checklist, some people would like SC level, others maybe Techniques level ?
• initial decision: One tool for developers and evaluators - maybe with filtering (described above). (rather than separate tools)
• Ideally this would work for ATAG & UAAG, as well. And perhaps in the future would integrate them all (WAI 3.0).
• EOWG asks: and possibility of retitling this? [Note: "How to Meet x.x.x" is used throughout http://www.w3.org/TR/WCAG/]
• Need to do SEO so this comes up first for searches such as "WCAG checklist" and "WCAG 2.0 checklist"
• AWK: Need to represent AND relationships in technique listings