W3C home > Mailing lists > Public > public-wai-evaltf@w3.org > October 2011

RE: use-cases and scenarios for conformance evaluation

From: Aaron Leventhal <aleventhal@rim.com>
Date: Wed, 19 Oct 2011 14:28:44 -0400
To: Shadi Abou-Zahra <shadi@w3.org>, Eval TF <public-wai-evaltf@w3.org>
Message-ID: <600E102A81A3BD42BF087D2397E706920228ACACED@XCH108CNC.rim.net>
Use scenario:
Planners, developers, testers at an organization working to remediate a large amount of web content. Organization wants to do a good job for end users, but has a limited budget. The organization needs requirements which do two things:
* Maximize user benefit -- both for users with disabilities and all users when possible.
* Minimize unnecessary costs, e.g. "busy-work" or complete rewrites where it doesn't make sense, as those resources should be used for other important work.

Use cases:
1. Determine whether it is necessary to support techniques with no perceivable user impact in order to maintain WCAG conformance, given a known set of supported target browsers for the content.
	Example A: What is sufficient for identifying semantics and structure (1.3.1)? Specific example: on a site targeted to mobile browsers where navigation by quotation is not available in ATs, is it necessary to mark the <blockquote>s? 
	Example B: Parsing errors (4.1.1) apply only to legacy ATs that are not available for many content targets. Is it necessary to conform when all target user agents can consume the content? 
9. Determine which techniques are acceptable for conformance in a mobile application targeting only user agents on current generation small-screen devices. 
Examples: 
	Example C: On a mobile site with a very small number of links at the start of each page, is it necessary to provide a mechanism to bypass blocks (2.4.1)? 
	Example D: Is it necessary to follow SCR21, "Using functions of the Document Object Model (DOM) to add content to a page (Scripting)" -- the technique rejects innerHTML as not part of the spec (it is part of HTML5), and rejects document.write in all cases (should be sufficient if used as part of the page load script). 

2. (Similar to #1, but for "near zero" rather than "no" user impact) Determine whether a technique with an absurdly low user impact is necessary to implement:
	Example: On a mobile site with a very small number of links at the start of each page (e.g. 3), is it necessary to provide a mechanism to bypass blocks (2.4.1)?

3. Determine which techniques or sub-techniques are equivalent and can be used in place of each other. Determine when one, more than one, or all of the equivalent techniques should be used.
	Example A: Determine which technique(s) are sufficient for bypassing large amounts of content (headings, skip links, ARIA landmarks, high level HTML 5 elements like <article> etc.)
	Example B: the organization is retrofitting accessibility on its website and has data describing what ATs are typical for site visitors. The site is targeted to be conformant by 2014. The organization wants to implement the most usable solution for the target users with disabilities. Determine whether it is preferable to provide form entry guidance (descriptions, error messages, required, invalid, etc.) via HTML4, HTML5 or ARIA.

4. Determine whether techniques using modern markup can be used in place of traditional techniques.
	Example: For a site targeted to a limited number of browsers, determine the appropriate labeling mechanism for a search field with an inner label. 

5. Determine whether a documented technique on a site external to W3C is sufficient for conformance.
	Example: Document conformance when using role="alert" for error identification (3.3), where the technique was provided on a well-known, highly credentialed accessibility checklist (e.g. in IBM web accessibility checklist).

6. When a given technique is not part of WCAG 2.0 techniques, determine how to sufficiently document it and remain conformant.
	Example: Document a long description technique which uses aria-describedby, such that it can be used in a conformance statement.

7. Determine whether the use of alternate conforming versions is conformant overall.
	Example: A video tutorial for email set up provides a link to alternate versions: "Setting Up Email for Screen Reader Users", and "Setting Up Email for Screen Magnifier Users". The alternate versions are clearly more usable than an audio described version where the ATs are running. Determine whether the links to the alternate versions are sufficient for conformance.

8. Determine whether techniques used in an app are "accessibility supported". 
	Example: an organization is faced with making an advanced calendar app accessible, either by adding ARIA markup to it or by writing a new version in static HTML. Writing a new version would be more expensive and have limited applicability. What data (surveys, site analytics, online docs, etc.) would be sufficient to show that the proposed ARIA techniques are accessibility supported and WCAG conformant?

9. Determine whether a 3rd party library can be used while conforming to WCAG.
	Example A: an organization uses a 3rd party open source JavaScript widget library which was made accessible through a great deal of effort by the industry. The developers of the library claim that every effort has been made, but will not claim conformance to WCAG. The accessibility lead must determine whether to recommend against using the library because of legal requirements for WCAG compliance.
	Example B: an organization uses a 3rd party closed source Flash widget library, where every effort has been made for accessibility, but WCAG conformance has not been claimed. Manual testing with a variety of end users with disabilities shows satisfactory results. Is conformance even possible in this scenario?

10. Provide requirements to internal/external teams for checkpoints or techniques which do not lend themselves to automated testing, for remediation of a large website.
	Example: satisfy conformance for checkpoint 2.4.6 -- "Headings and labels describe topic or purpose", while remediating a 30,000 page website, given that manual checks would be required. Spot checks seem reasonable, but this is using common sense as opposed to conforming to WCAG language. Determine what's appropriate.

Hope that helps,

Aaron

> -----Original Message-----
> From: public-wai-evaltf-request@w3.org [mailto:public-wai-evaltf-
> request@w3.org] On Behalf Of Shadi Abou-Zahra
> Sent: Wednesday, October 19, 2011 11:44 AM
> To: Eval TF
> Subject: use-cases and scenarios for conformance evaluation
> 
> Hi folks,
> 
> As part of the requirements, what do people think of collecting some
> different use-cases and scenarios for conformance evaluation?
> 
> We could use these to have specific examples to design to and also to
> verify the Methodology. Please send your favorite use-cases and
> scenarios to the list and I will collect them into a web page.
> 
> Best,
>    Shadi
> 
> --
> Shadi Abou-Zahra - http://www.w3.org/People/shadi/
> Activity Lead, W3C/WAI International Program Office
> Evaluation and Repair Tools Working Group (ERT WG)
> Research and Development Working Group (RDWG)


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Received on Wednesday, 19 October 2011 18:30:15 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:52:12 GMT