Important note: This Wiki page is edited by participants of the EOWG. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Working Group participants, WAI, or W3C. It may also have some very useful information.
Eval Analysis
From Education & Outreach
(Difference between revisions)
(→Tasks & Use Cases: simplify some of the EM scenarios) |
(→Preliminary Evaluation Analysis) |
||
| Line 107: | Line 107: | ||
==Preliminary Evaluation Analysis== | ==Preliminary Evaluation Analysis== | ||
| - | === | + | ===Audience=== |
Primary audience: | Primary audience: | ||
| - | * Non-technical people with low accessibility | + | * Non-technical people with low accessibility knowledge who want a general idea of the level of accessibility of a web page |
Secondary audiences: | Secondary audiences: | ||
* Newbie accessibility evaluators who want to dive in progressively | * Newbie accessibility evaluators who want to dive in progressively | ||
| - | * Knowledgeable evaluators who | + | * Knowledgeable evaluators who want to run very high level evaluation only |
| + | |||
| + | ====Misc==== | ||
| + | * Focus on one web page, as opposed to broader issues of selecting representative pages, etc., which is addressed in WCAG-EM | ||
| + | * For this draft we have some tool-specific guidance. However, there are potential issues with vendor-neutrality and we might need to address this a different way — for example, moving tool-specific guidance to [http://docs.webplatform.org/wiki/Main_Page Web Platform Docs] or the [http://www.w3.org/community/wai-engage/wiki/Main_Page WAI-Engage wiki] where people can easily add tool-specific info. | ||
| + | * ... | ||
| + | |||
| + | ===Criteria for checks=== | ||
| + | These are draft ideas for now; they might change. | ||
| + | |||
| + | ====Criteria for short list (5 min checks)==== | ||
| + | * Do-able with system limitations - does not require downloaded tools or a specific browser | ||
| + | * ... | ||
| + | |||
| + | ====Criteria for longer list (15 min checks)==== | ||
| + | * Common accessibility barriers (what we see often as mistakes in web pages) | ||
| + | * Easy to understand | ||
| + | * Not complicated issues (not if lots of debate on forums) | ||
| + | * Not likely to give false positive or false negative; pass-fail not complex | ||
| + | * Checks that clearly related to specific WCAG success criteria | ||
| + | * Checks that don't require seeing visual rendering of page | ||
| + | * ? easy of fixing | ||
| + | * ? has good example in BAD | ||
| - | |||
| - | |||
| - | |||
| - | |||
__NOINDEX__ | __NOINDEX__ | ||
Revision as of 17:11, 30 November 2012
Nav: EOWG wiki main page
Related pages: Web Accessibility Preliminary Evaluation, Eval in process
Contents |
Tasks & Use Cases
The following table lists tasks, example user cases with audience, and focus for each document. (Note that we haven't decided whether or not to do a new doc on evaluation in the process.)
| task | example use cases | prelim | conform overview |
WCAG-EM | process | |
|---|---|---|---|---|---|---|
| Get general idea of accessibility of a webpage (major problems, some issues, maybe OK) |
|
mostly | maybe some | |||
| Get an overview of WCAG-EM |
|
maybe | lots | maybe just a little | ||
| Thorough, authoratative evaluation of WCAG conformance |
|
maybe at first | mostly | |||
| Evaluate throughout design and development process |
|
some | lots |
Notes
- I have added some extra use cases. I wanted to have different types of websites: large and small websites, whole websites and sets of pages or new sections, and different types of developers/evaluators: inhouse and agency developers, third party evaluation, and also maintenance (I think its important!) I would like to discuss them and any other variations that anyone wants to add. To help discussion I turned the bullets into numbers. Also, I fixed a table format problem that I caused, but not the alignment issue. {Suzette}
Use case for preliminary evaluation
{@@dboudreau - 20120928} First draft - proposal
- Vendor is commissioned to develop a WCAG 2.0 or Section 508 compliant website
- Client wants to know if the vendor actually delivered an accessible website, but doesn't have the skill set to really measure it.
- Client uses the Preliminary Evaluation process (simple tests) to check for basic things like alts, keyboard nav and headings on random pages.
- Client determines if the website passes those tests or not, based on the tests results.
- If the website passes those tests, then client or designated technical person digs further with additional informal tests.
- If the website doesn't pass those tests, then client commissions a technical profile to integrally follow the WCAG-EM methodology.
- Find and fix - developer, or content editor tests newly added content and fixes commonly occuring missed elements eg text alternatives, form elements, link labels, text resizing and colour contrast prior to release or more in depth evaluation. {Suzette}
- From Website Accessibility Conformance Evaluation Methodology 1.0. Preliminary is mentioned three times including 1.3, 2.0 and this one: 4.1:"Note: It is recommended to carry out preliminary reviews before carrying out a conformance evaluation to identify obvious errors and to develop a rough understanding of the overall performance of the website."{Suzette}
Preliminary Evaluation Analysis
Audience
Primary audience:
- Non-technical people with low accessibility knowledge who want a general idea of the level of accessibility of a web page
Secondary audiences:
- Newbie accessibility evaluators who want to dive in progressively
- Knowledgeable evaluators who want to run very high level evaluation only
Misc
- Focus on one web page, as opposed to broader issues of selecting representative pages, etc., which is addressed in WCAG-EM
- For this draft we have some tool-specific guidance. However, there are potential issues with vendor-neutrality and we might need to address this a different way — for example, moving tool-specific guidance to Web Platform Docs or the WAI-Engage wiki where people can easily add tool-specific info.
- ...
Criteria for checks
These are draft ideas for now; they might change.
Criteria for short list (5 min checks)
- Do-able with system limitations - does not require downloaded tools or a specific browser
- ...
Criteria for longer list (15 min checks)
- Common accessibility barriers (what we see often as mistakes in web pages)
- Easy to understand
- Not complicated issues (not if lots of debate on forums)
- Not likely to give false positive or false negative; pass-fail not complex
- Checks that clearly related to specific WCAG success criteria
- Checks that don't require seeing visual rendering of page
- ? easy of fixing
- ? has good example in BAD
