Meeting minutes
hdv: For those who don't know, WCAG is Web Content Accessibility Guidelines, describing how you can make web content accessible
… used by legislation all around the world, to establish or help people establish what is needed to be accessible
… need to evaluate whether things need WCAG, and that's where WCAG-EM comes in
… I'll briefly describe what's in WCAG-EM. Current version is 1.0, came out in 2014, over 10 years ago now
<Ben_Tillyer> Link to WCAG-EM: https://
hdv: provides a procedure to evaluate how well websites conform to WCAG
… it's a procedure. Doesn't say much about accessibility; says how to measure it. How to establish scope, how to select a sample
… e.g. how to select a representative portion of a website if you have a site with a thousand pages
… also guidance to report on what you found
… meant for use on existing websites. You've built a website and want to know how well it conforms.
… can also be used during development.
… meant to be technology-agnostic, but quite specific to the web
… important to note it is a process. It's not anything that adds any new requirements
… it's a document that makes suggestions on how to structure your evaluations, it's not a document that requires anything
… You start with defining evaluation scope, then explore target website, select a representative sample, then audit the selected sample.
… Diagram shows arrows pointing both forwards and backwards between steps
… WCAG-EM gives us a way to establish if a website conforms to WCAG, especially if it's too big to look at everything.
… it's also a way to ensure consistency between reports, and make them comparable
… this has been extremely important at Logius working with the Dutch government
… we need to look at almost 9,000 websites. Every member state of the EU has to do something like this
… and each of those websites could have over a thousand pages
Link to Dutch dashboard of the ~9,000 websites: https://
hdv: because WCAG-EM results in the same structure across reports, it allows to build dashboards
… and WCAG-EM is not something just for us, it's something that anyone can use
… procedure is intended to be helpful to more people.
… We think it's time to work on the next version, WCAG-EM 2.0
… a few of us in AGWG have been working on this for about the last 7 months.
… including Hidde, Jeroen, and Steve Faulkner
Link to WCAG-EM 2.0 Editor's draft: https://
hdv: lots of small bits (editorial), fixes to URIs and spelling, improved wording
… trying to align with the style guide for WCAG 3 that Tamsin is working on
… these are not exciting changes but I'm glad we've been doing them
… the more exciting change is we've been trying to broaden the scope of WCAG-EM
… try to make it more abstract to be applicable to more than just websites
… we've replaced 3 terms, to make it compatible with not just websites, but also apps, kiosks, and other things that you want to know how accessible they are
… replace "sample" with "sample set", then replace "web page" with "view" or "sample"
… and replace "website" with "digital product", to align with European legislation and other places
… WCAG 3 may be aligning with the latter as well
<JJ> And the WC part was Web Content and is now W3C, like WCAG3
hdv: finding this useful for design systems as well
… Currently getting ready for Draft Note status
… which is the step before an actual Note
… will work on updating report tool
… Looking to open discussion for questions and ideas
… what would you expect in a modern methodology for evaluating WCAG? Are there ways we can make it more effective? More trustworthy?
JJ: I'd like to say I'm really happy about this new development. Also something we've been trying to do with our foundation; we've made our own version of EM previously, Appt-EM
… I'll need to check the latest changes in the draft, no questions at the moment
LenB: Something for us that'd be helpful is an evaluation method for design systems
… before a page or a view exists, is there a way to evaluate a design system with a meaningful report?
… With the way that Figma and other tooling works now, there may be something interesting in how those things come together.
… could take a snapshot and somehow apply it
… Another thing I was thinking the other day is, plain language is not on my designers, it's on the content strategy team, marketing teams, etc. on the client side who consume our design system
… is there something we can pass on to them to ensure they are using our guidelines?
… if I can prevent the issues in creation, then when we get to evaluate the final thing, we'll have already knocked out a lot
hdv: We're talking a lot about how to deal with conformance claims in AGWG as well
… something in the design system is too small to make a conformance claim about
… maybe WCAG-EM can work with that
… with a design system, you want to know whether the building blocks are good from an accessibility perspective
LenB: There's a sister component as well, we run checks on our storybook repos before engineering picks it up and brings it into the UI.
… It's not that great in the sense that it's still in a wrapper, but it can at least check that component
… e.g. there could be 14 ways to screw up a text input component
hdv: There could be things to verify or check inside a component
LenB: Wondering if there's a way to adopt this to bring to a design system
hdv: Maybe this is something we can bring up with AGWG; it's a great question
JJ: If you can catch issues in the design phase, it can prevent a lot of issues in development
… I wonder how it would be implemented, e.g. in Figma. Maybe not a full conformance claim
hdv: Some of the accessibility problems you might expect, might not exist yet within the design phase
… RE authoring tools, that's another angle you mentioned, that's also a really good way to do things
… ATAG is looking to revamp
LenB: I do think this will be easier to do with 3.0 than 2.2, e.g. around plain language assertions
… we specifically avoided passive voice guidance, and said it has to be an assertion. It's a thing we can check, but we can't say that all legal sites have to be active voice
Tamsin: Passive voice is needed in some cases; it's contextual
Ben_Tillyer: Whenever I found a problem with something in Figma, I identify the node ID, right click and copy the URL and it's in the URL, which makes it easy for someone to jump to it
… We have millions of web pages across many subdomains. Within different platforms we have different templates and themes. Issues could come from a content author, a template that's in use, or something else.
… What I've found useful when collecting other people's thoughts and accessibility findings, is for them to say where they think it's coming from
… There's one accessibility company I know that is working on reporting whether a shared component has caused an issue and sharing that information
… it'd be really good if we could have a source/cause; then could make use of filtering
hdv: Sometimes auditors don't know, sometimes they do, e.g. if they're sitting next to the developer
Ben_Tillyer: Auditors may use xpath or some way to select an element, to attempt to help the company work out the issue
… another source of defects can be a quirk of some AT
JJ: Something missing for apps is you don't really have a URL there. Apps may allow you to include a screenshot. Can be hard to get back to a specific state to reproduce.
… if there are no further questions, maybe spend some time to go through the document?
Sayaka: Can components individually conform to WCAG, but then fail to conform when combined in a certain way?
hdv: May be worth evaluating in terms of smaller pieces; I know design system teams tend to test accessibility as well. It's not really a WCAG-EM kind of thing
Ben_Tillyer: I know this won't help EM, but I've found that one of the key things you can have in a design system is to have really clear documentation regarding how a component can be used
… one of the common sources of accessibility defects I've seen is when developers use design system components in a way they were not designed for
LenB: Something we do is we will identify in our documentation anything that must be included, e.g. alt text
… this will kick off a set of checks
… the other thing we do is double-check things like interactions.
… e.g. with a modal, what happens when the user returns from the modal? They should return to trigger, which means you should not remove the trigger before the user returns from the modal
… the design system needs to mature well past the component to determine how those kinds of things come together
… I have been trying to figure out how to determine missing instructions. One way is to examine our list of defects
… We could totally do this in Figma; there are other tools that are harder to check because we don't have the documentation tools for it
… onboarding process becomes longer
hdv: I've seen in a lot of design systems that they're used as an opportunity to explain to people how to build accessible stuff, which can be really cool if it's done well, e.g. with annotations
… starting to think a group note on this subject could be interesting
… a lot of people are starting to evaluate their design systems as well as their websites
Sayaka: We tend to put everything in the design system in Figma
LenB: which is not accessible, so half my team can't use it
… users end up having to pair up to get into it
Ben_Tillyer: I know there's some things going on with ARRM; if components can be responsible for an issue, then a role could be responsible for an issue as well
… if ARRM finally gets mature and published, maybe it would be useful for organizations to put them in different buckets
hdv: Great suggestion to see if we could embed or cross-link ARRM
<Ben_Tillyer> Link to Accessibility Roles and Responsibilities Mapping https://
hdv: we don't describe accessibility problems, we say you have to write down the results of your evaluation
… but that's something on our backlog, to say what is a good way to describe what's wrong
… could say to write down whose responsibility it is, can help resolve the problem quicker, if you know what department to assign it to
Kenneth: Curious if can of worms was found after chosing for view instead on page
hdv: We've gone for view everywhere, trying to align with what we agreed on in WCAG 3, but I think we might need to correct to page/view in some cases
… I think how we've done it is used "sample" to refer to both of those as a more abstract way of talking about it, but that may be making it more complicated
… a lot of evaluators we talked to said they use sample or sample set instead of web page
… if you're doing a lot of app audits, you might not be talking about pages ("screens")
… if we turn this into JSON or whatever, it's going to propagate elsewhere, doesn't matter what the category is called
… what's important is we use the more abstract term, then people can use whatever term they want as long as they're following the same process
LenB: Has anything been written on what to do with it? Or is that outside our scope?
hdv: In some cases regulators ask for it. e.g. countries in Europe
… people can upload it within their own domain, use it within their own system
<Ben_Tillyer> Link to WCAG-EM report tool https://
hdv: We have the WCAG-EM report tool that people can use as well
… I guess that's the closest we say to what you can do with it
… we've also added a link to this report in the newest version (not in the current version)
… the tool was built after the spec was written
<Zakim> Daniel, you wanted to ask about the WCAG-EM report tool
Daniel: So inside W3C we produce standards, we don't tend to get into regulation, but that's not to say we can't publish documents helping to explain how regulations can be framed around the specs
… regarding any update to the EM Report Tool, wondering if you could share this as well
hdv: Yes, it's not in the current charter, we're currently updating the process
… I've worked with the current tool; we don't need to touch the dangerous moving parts much, but would love to update the report tool in tandem
Daniel: I think this was under EO back in the day, so that's probably why it's not in the AGWG charter
<Ben_Tillyer> EU model accessibility statement which mentions "The [non-compliance(s)] [and/or] [the exemptions] are listed below" link: https://
<Ben_Tillyer> https://
hdv: I think it would be great to do, either people from W3C or from our little group
… we've had some other people reach out that would be happy to work on it
… also need to think about transition between WCAG-EM 1 and 2. There will still be people who want to use the current tool
Ben_Tillyer: For the Public Sector Body Accessibility Regulations (UK) we're expected to put the findings we would ostensibly get from WCAG-EM
hdv: There is nothing similar; people build their own tools
[mention of German and French tools / procedures]
hdv: any last thoughts?
Link to BITV (German evaluation method): https://
hdv: this session is not the only thing. This work will continue. If you think of things in the coming days/weeks, can file issues on GitHub or join the slack channel #agwg-wcag-em, or email any of us
… very much open to ideas of how to make evaluation better
… thank you all for attending this session