Easy Checks 2022

From Education & Outreach

Current Work

For EOWG:

Pull Request with current work, previews

Links

Latest:

EOWG 2023 minutes, issues, etc:

Others:

Previous info:

EOWG Discussions and Surveys

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

Retrieved from "https://www.w3.org/WAI/EO/wiki/index.php?title=Easy_Checks_2022&oldid=39118"