Easy Checks 2022
Current Work
For EOWG:
- Comment on prioritization of potential checks. See Instructions for prioritization of potential checks (Google sheet)
- Comment on How many checks? (GitHub)
Pull Request with current work, previews
Links
Latest:
- Pull Request with current work, previews
- prioritization of potential checks (sheet)
- project timeline, content creation status, etc. (sheet)
- Google Drive folder with docs
EOWG 2023 minutes, issues, etc:
- @@ add minutes links
- How many checks? (GitHub)
- 10 March 2023 minutes
- 2019 survey question on bookmarklets
Others:
- Easy Checks Prototype Usability Testing May 2023 at AccessU (doc)
- miro (not accessible, all relevant information will be provided for EOWG and everyone in an accessible format)
- old prototypes: @@ date, @@ <May usability testing version A>, @@ <May usability testing version B>
- old possible checks that was turned into spreadsheet
- Google Drive folder with docs
Previous info:
- Easy Checks current version
- 2022 Analysis and user feedback by new project contributors
- 2017 Easy Checks Next Gen has some ideas for improvements
- 2015 Requirements Analysis and Issues includes criteria for checks, discussion of flow, and more
EOWG Discussions and Surveys
- Sept 2023 at TPAC - card sort exercise results
- 4 April 2023 minutes
- December 2023 Easy Checks Starfish review survey (detailed)
Update: Please put comments in GitHub instead of adding to this wiki page. You can open a new issue and comment on existing issues:
Requirements Analysis
Requirements Analysis is an internal document (that is publicly visible). Thus it does not need to have polished wording. Avoid un-important word-smithing.
Purpose
Guide users without much accessibility knowledge to check web pages for some simple accessibility issues.
Background
Easy Checks is one of several Test and Evaluate resources and related getting started resources. The current version of Easy Checks was developed in 2017 and is ripe for an update. The main issues with the current version are documented in previous “Next Gen” ideas and recent analysis. Summary:
- Content: The current content is partly outdated, for example, screenshots are of old browsers.
- Ease of use: It currently presents a lot of textual and detailed information, getting in the way of a pleasant user experience and its main purpose. This relates to ease of finding, ease of understanding, and ease of using the relevant information.
- Checks: It currently provides instructions for using browser toolbars. This may present a significant hurdle for some users. We are exploring if providing instructions for bookmarklets/favlets would be a more user-friendly and light-weight approach.
open issue - bookmarklets, browser toolbars, other tools, etc.
Goals & Objectives
- Communicate the goal of Easy Checks and manage expectations. Make sure users understand that it is a not a full or definitive review of accessibility.
- Provide users with checks of web content. (what can I do)
- Provide guidance on how to perform these checks. (how can I do this)
- Provide links for users who want to learn more.
Target Audience
Primary audience:
People with low accessibility knowledge who want:
- a general idea of the level of accessibility of a web page
- to start learning about evaluating accessibility
Including:
- Non-technical people (e.g., procurers)
- Technical people (e.g., coders)
Secondary audiences:
- Newbie accessibility evaluators who want to dive in progressively
- Knowledgeable evaluators who sometimes want to run a few quick checks (e.g., for potential clients)
Audiences out of scope — people who might end up on the page and should be pointed to a resource that is more suitable to them:
- Users who know nothing about accessibility (direct them to WAI's Introduction to Web Accessibility first).
- Users wanting guidance on conformance evaluation.
- Users wanting solutions to accessibility problems.
More details in Use Cases section below.
Use Cases
The following users have a little knowledge of accessibility, not much.
Checking expected accessible pages:
- Procurer — Pat is responsible for contracting a vendor to do a promotional campaign for a major product release. The campaign includes creating web pages and social media content. The RFP/RFT includes accessibility requirements. Pat wants to check the potential vendors’ websites -- and other projects that they submitted as examples -- to see if they covered basic accessibility issues.
- Project manager — Maadai commissioned a website that is suppose to meet WCAG. Maadai just received the first prototype and wants to do a quick check to see how it is on accessibility. (They will do a thorough evaluation on later prototypes.)
- Employer — Emiko's company is hiring a web designer position that requires accessibility knowledge. Emiko is doing the first level screening of applicants. Emiko wants to check applicants' websites -- and other projects that they submitted as examples -- to see if they covered basic accessibility issues.
Teaching, mentoring:
- Instructor — Ishmael teaches a class on digital accessibility. Ishmael uses Easy Checks as an introduction to website evaluation. Ishmael asks students to read Easy Checks, use the guidance to check web pages, and write a report on needed corrections.
- Mentor — Mandala is guiding a new employee in the company to learn about accessibility. Mandala instructors the employee to read through the WAI fundamentals resources and then use Easy Checks on some sample web pages. (Or, to complete the WAI fundamentals course, which uses Easy Checks.)
Other tasks:
- Link checker — Li is providing a list of links for additional information [for a course lesson, for a blog post, for whatever]. Li doens't want to link to pages with significant accessibility barriers. Li uses Easy Checks to get an idea of whether or not the pages cover some basics.
- Advocate — Aleksander (who has a disability) encountered an accessibility barrier trying to use a website. Aleksander wants to know if there are many other problems or not. That will help Aleksander decide how to report the problem — e.g., "It looks like you've avoided many accessibility barriers, here's one you missed..." or "It looks like your website has many accessibility barriers, e.g.: ...".
These use case are examples. There may be other use cases. e.g., potential additional use case - content author/designer ?
Functional Requirements
Primary
- Offers options to easily check web content for some accessibility barriers.
- Checks should ideally not-require any installation and work in stringent security environments.
- Checks should require minimal technical knowledge to complete.
- Provides short information on why this check is important and who benefits.
- Provide clear information on what 'good' and/or 'bad' results for the checks look like.
- There should be easy, straigh-forward instructions on how to perform these checks.
- Provides a clear overview of all checks to easily find those that seem most relevant.
Out-of-scope
- Does not address "conformance". Does not provide a complete and authoritative verdict on the state of accessibility of web content.
- Does not give complete and detailed info on the different accessibility subjects related to the checks.
- Does not provide direct solutions to accessibility problems. (can link to some guidance)
User Experience & Usability Requirements
for Jasper: questions on User Experience & Usability Requirements #129'
Guidance
- The goal of Easy Checks is prominently displayed and the starting point for visitors of the resource in such a way that it sets an accurate expectation.
- The checks have easy to understand headings that indicate their relevancy for the visitor.
- It offers a clear ‘route’ to guide visitors where to go and what to do.
- It allows visitors to easily skip this prescribed route and directly jump to specific checks.
Content
- It offers information one subject at a time with to-the-point text, so that it can be consumed in a small amount of time and the visitor does not get overwhelmed with information.
- Text is written in ‘plain language’, avoiding jargon and technical terms where possible or with explanations only when absolutely needed.
- Textual information is supported by visuals where possible.
- Visual examples are abstracted in such a way that they convey close familiarity to real-world applications (web browsers), while remaining platform agnostic and future-proof.
Approach
@@
Related Resources from Others
- Easy Checks Protocol from Yale University is a simplified checklist based on WAI's Easy Checks. It also includes Optional Additional Checks.
- Beginners' Guide to Accessibility Testing includes Testing without tools
- Quick Accessibility Tests
- more listed in DuckDuckGo, Google
- Top Ten Most Common Web Accessibility Issues
- tweet thread: What are some digital accessibility hills that you are prepared to die on? has some interesting perspectives.