- From: kamyar <kamyar.rasta@tingtun.no>
- Date: Tue, 24 Jun 2014 18:27:48 +0200
- To: public-auto-wcag@w3.org
Automated WCAG Monitoring Community Group Teleconference 2014-06-12, 16:00 - 17:00 h (CET) Attendees: Hanno Lans John Hicks Kamyar Rasta Wilco Fiers ITEM 1 Formal language for test creation John: Firstly, RGAA (a web accessibility guideline in French) [1] might be a good model to follow as WCAG is not precise enough. There is specific language RGAA which breaks tests down in two parts: selectors and test methodology. The test methodology is broken down into binary test so there is yes and no for each level. Secondly, maybe RGAA is not formal enough also and we might turn it to a conditional language in pseudocode. As next step I like take 4-5 tests and formalize them using RGAA. Wilco: the format is nice and similar to our approach but it is better to enhance the plain text a bit to make it more readable. John: we can format it or even add something like have especial way of put in that in a XML like or having look at how EARL does it when it describes the result language. John: Will send the English translation. John: I will look to see if there is any description of RGAA. But you could also use the examples to inspire the description. Wilco: Is it open is this? John: Yes, I did the translation personally two years ago. And we don't mind. Wilco: we can see if we can take test steps are in here, and move them in to the format that we are proposing to use. kamyar: look at [4] to see how concise is this from respective of developer. What are the ambiguities there. ITEM 2: Creating test descriptions with Quail Hanno updates: a quail test example here [2]. This is a script to detect if a table is data table or layout table. This is an import test because it is used by other tests. Wilco: So we could treat this as a selector. Is this data table or not. Hanno: the first selector is table and then we have this especial selector to refine that selector. Wilco: the next step is to see if we can take the code and text there and write it down in the format that John mentioned. John: Introducing headings like what we see in [2] is good idea because it tells you what the step is about. One thing I can do it to put heading before each test to describe what the test is. Hanno: not all quail tests are documented in this way [2]. Wilco: We can potentially use some the quail code and document them in this way. That would benefits both our project and quail. Hanno: Issue list of quail [3]. we mainly focusing on failure and techniques. We try to connect failure to techniques and techniques to each others. Hanno: will provide a simple list of quail tests for the community group as test description. Will focus on something like four simple success criteria. ITEM 3: Planning test development Wilco: setup a wiki page contains different SC and assign name to them. For each SC that person is going to write different tests. References [1] http://references.modernisation.gouv.fr/sites/default/files/RGAA-v2.2_Annexe2-Tests.pdf [2] https://www.w3.org/community/auto-wcag/wiki/IsDataTable [3] https://github.com/quailjs/quail/issues?direction=desc&labels=success+criterion&page=1&sort=updated&state=open [4] http://lists.w3.org/Archives/Public/public-auto-wcag/2014Jun/0006.html Summary of action items: https://www.w3.org/community/auto-wcag/wiki/Action_items kamyar: look at example that John gave [4] as email and find any potential problem from developer's perspective. Hanno: Tests of Quail, the list of SCs that are automatically testable and working on some of the script descriptions. John: Send translated version of the proposal (RGAA) and see how well they are implementable in some of WCAG's success criteria. Find out if there is any description for RGAA. Wilco: create a proposal on how to format new WAM language for the test. And create the list of SC where people can assign their name. Best Regards Kamyar
Received on Tuesday, 24 June 2014 16:28:20 UTC