RE: Takeaways WPT & ARIA test harness

Thanks Wilco, and Alistair. 

 

Not only is this a really good idea, we need to have a reference and research section that includes some of the rationale behind our work.

 

That is NOT to suggest that we cannot use and come up with our own good ideas (so that this work can be referenced in much the same way by others)!

 

​​​​​

 

 

 

* katie *

 

Katie Haritos-Shea 
Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA)

 

Cell: 703-371-5545 |  <mailto:ryladog@gmail.com> ryladog@gmail.com | Oakton, VA |  <http://www.linkedin.com/in/katieharitosshea/> LinkedIn Profile | Office: 703-371-5545 |  <https://twitter.com/Ryladog> @ryladog

 

From: Alistair Garrison [mailto:alistair.garrison@ssbbartgroup.com] 
Sent: Wednesday, October 5, 2016 7:26 AM
To: Wilco Fiers <wilco.fiers@deque.com>; public-wcag-act@w3.org
Subject: Re: Takeaways WPT & ARIA test harness

 

Hi, 

 

>From a quick bit of research this week – sorry.

 

Accessibility testing is effectively an extension of User Acceptance Tests—in effect, ascertaining if a product (e.g., web site or web application) enables users, including persons with disabilities—to complete all specified tasks, whether are using Assistive Technology (AT) or not.

 

Accessibility tests are generally written to ensure positive accessibility features have been implemented or that negative features have been avoided. Ideally, features are defined in terms of testable statements that can be made about the product. 

 

*         Positive feature: A skip link is provided at the top of a page that goes directly to the main content area. 

*         Negative feature: No displayed content in a page flashes more than three times per second.

 

As such, accessibility tests can be written following the same well-established software testing best practices that we use to write general acceptance tests, for example:

 

1)            When covering a feature, write a test procedure that contains several simple test steps rather than a few complex test steps.

2)            Ensure each test step checks for one thing.

3)            Write each test step in plain English (avoiding pseudo-code).

4)            Ensure each test has an expected result that is clearly defined.

5)            Ensure each test is independent. It should be able to run on its own, not affect other tests if changed, and not be affected by changes to other tests. 

 

Section 11 of IEEE 829-2008 contains details of environmental needs that should be documented – for example, hardware or software needed, etc.

 

Very best regards

 

Alistair

 

From: Wilco Fiers <wilco.fiers@deque.com <mailto:wilco.fiers@deque.com> >
Date: Wednesday, 5 October 2016 at 10:23
To: "public-wcag-act@w3.org <mailto:public-wcag-act@w3.org> " <public-wcag-act@w3.org <mailto:public-wcag-act@w3.org> >
Subject: Takeaways WPT & ARIA test harness
Resent-From: <public-wcag-act@w3.org <mailto:public-wcag-act@w3.org> >
Resent-Date: Wednesday, 5 October 2016 at 10:24

 

Hi team, 

I've updated our wiki page with some research I did about WPT & ARIA. I think there are some interesting ideas here for us to consider.

 

https://www.w3.org/WAI/GL/task-forces/conformance-testing/wiki/Testing_Resources#Take-aways_from_WPT_.26_ARIA_Test_Harness


 

-- 

Wilco Fiers - Senior Accessibility Engineer