Session 1: WAI-Tools Project Overview

This video information is available:

Audio Description

This video does not include audio description because the visuals only support the audio and do not provide additional information. In this case, audio description would be more distracting than useful to most people, including people who cannot see the visuals. The Transcript with Description below includes descriptions of the supporting visuals.

Text Transcript with Description of Visuals

This is video is accompanied by slides 01

Visual Audio
[Shadi speaking]
Slide 1: About the Project		 Just a little bit about the project itself. WAI-Tools Project is an acronym for Advanced Decision Support Tools for Scalable Web Accessibility Assessments of the Web Accessibility Initiative. So, WAI-Tools.
So, it’s a project of the W3C Web Accessibility Initiative co-funded by the European Commission, the EC, under the Horizon 2020 program. It’s a so-called Innovation Action project. So there are different types of projects that the European Commission supports and this is one of them. It’s under the line of innovation action.
It started on the 1st of November in 2017. It also – it already feels like many decades ago. And unfortunately actually, coming to an end at the end of this month. As I mentioned, it’s been a really great project, great fun working with the partners.
Slide 2: Project Partners Speaking of the partners of the project, the lead partner is the European Research Consortium for Informatics and Mathematics, ERCIM which is the European host for W3C. So, this is the legal footing of W3C in Europe.
Other partners in the project are Siteimprove from Denmark, the Accessibility Foundation in the Netherlands, the Norwegian Digitalisation Agency, Digdir, and the Administrative Modernization Agency in Portugal, AMA. The University of Lisbon, FCID, in Portugal, and Deque Research which is based in the Netherlands.
So, these are the project partners who together are responsible for moving this forward, this project, but really a lot of this work is happening or happened in – directly in open W3C groups and we’re going to be talking more about that, about how the project work has happened and how you can still contribute to some of this project work which is going to continue happening in these groups.
Slide 3: Objective 1 But just to give you a little bit of the objectives of the project, what did we really want to achieve with the project? One of the main objectives here on the screen is an illustration where at the very top of the illustration is kind of the ultimate goal. We all want compatible results, right?
When we are evaluating for the Web Content Accessibility Guidelines which is the layer below, we’re evaluating for accessibility or testing for accessibility, we’re using different methodologies, so different methods. But at the end of the day, we’re testing for the same set of guidelines and we want to get compatible results. We want to get the same results when we test the same things, right, no matter how we actually test them.
Same slide; highlight around "ACT Test Rules (open royalty free)" middle layer of the diagram And so, this was really the focus of the project, to look at what we call ACT test rules, Accessibility Conformance Testing rules. The point is these are very, very small procedures for testing that can be combined together for different methodologies. And methodologies here is a broad term. It could be automated tools or anything. Any procedure that you follow for manually checking, this is a methodology as well. So, really, anything that encodes how you check accessibility is a methodology. It could be manual. It could be automated. It could be a combination, semi-automated, so a combination of automated and non-automated approaches together.
So, if we have very small building blocks, and they are depicted here as these small boxes, these small squares, very, very small, like Lego pieces, we can combine these together to provide different methodologies but at the end of the day, if we test the same thing, we want to get the same result.
So, that’s really the objective or the vision of the project is to try to get consistency because we know that one of the big issues of accessibility right now is that we don’t have that consistency. We have different tools that provide different results or different evaluation methods. So, you go to one person and you get one result and then sometimes you can get slightly different results when you go to a different person to get it checked. That’s a big problem for accessibility that we’re trying to address to have more consistency of how we test.
Slide 4: Objective 2 Another objective of the project, by defining these checks and finally agreeing on them and not having to constantly re-repeat how we test certain things, how do we test the text alternative or how do we test the label. If we can finally decide and agree on a common interpretation for these checks, maybe we can increase automation in that.
Right now, a very large part of accessibility needs to be tested manually. But we also know that there is a lot of advancements happening in the technology. Buzzwords, artificial intelligence or machine learning, natural language processing. All of these technologies are evolving, all of these innovations that would essentially allow us to increase the level of automation.
It doesn’t mean that accessibility will be fully automatable, at least in the foreseeable future, but at least we can maybe increase the amount of tool support which would be – would make things much more effective and much more efficient if we can increase this level of automation.
Slide 5: Project Deliverables So, these are really the objectives or the core pieces of the project. The deliverables of the project, which we’re going to go into more detail, but hopefully from a more applied side, is the main part of the project, the heart piece is to develop Accessibility Conformance Testing rules, right. So, this is to create an initial set hopefully to get the work in the community kickstarted to help establish an active community that will sustain beyond the project. So, this is a call on – call for action for you to get involved in this work that will continue beyond the project.
We implemented these rules that we developed in different tools from project partners in the project, here specifically the partners Siteimprove in their checker called Alfa, in Deque in their checker called Axe-core, and in – a tool from the University of Lisbon in a checker called QualWeb.
And we also validated these rules in real-life situations. We had a set of websites that we took and that we ran these rules across.
Now, these rules were applied in different ways, were test-driven, or were taken up by the Portuguese and Norwegian observatories. These were part of the project to kind of really ground us and look at when entire countries want to do large scale monitoring of accessibility, what are their needs? What can we learn from that? And how can we provide them with different types of rules that will support getting them valuable information?
We looked at improving the existing WCAG-EM Report Tool. So, people might know that tool. It already existed. WCAG-EM stands for WCAG evaluation methodology. It actually has a longer name, Website Accessibility Conformance Evaluation Methodology. It’s a long name. But this is an evaluation methodology for WCAG that can be used to test entire websites. And it was a tool to help you walk through that and now we have added to that tool an import function so that you can import test results from automated tools, again here to show the idea that we can combine automated and manual when we’re using open standards here.
We also created an accessibility statements generator tool. So, this helps you create accessibility statements for your website once you have done the testing to explain to the world the accessibility that you have on your website.
And last but not least, a demo, a proof of concept to show, to demonstrate the potential of open linked data for accessibility. So, what if – right – what if we had these test results being published, at least those by public bodies, and we could connect these and we could scrape these and we could do a more active or decentralized monitoring approach?
Slide 6: Project Results and Furhter Information So, these are the project deliverables. More information is on the website. We will provide you these links at the end again so you don’t need to start looking at the links. The address is w3.org/WAI/Tools. That is the project page for the WAI-Tools Project and you can find here further information, all the resources, all the deliverables, including this open meeting with the slides online as well.
Back to Top