ATAG is a set of guidelines for the accessibility of authoring tools. In this post I'll talk about what it is and why it matters.
Most people working on websites will be familiar with WCAG, the Web Content Accessibility Guidelines. There are two more related standards, one for user agents (like browsers) and one for authoring tools (like CMSes, WYSIWYG or Markdown editors, e-learning platforms and website creators). They work together: if we care about the accessibility of web content, we should also care about how it is created (in authoring tools) and displayed (in user agents).
“Web content” in accessibility standards refers to websites, apps and other content on the web. I like to think of it as the HTML that browsers serve to the user when they access your website or app. There isn't a definition for “web content” in WCAG, but there is one for “web content technologies”. From that definition we can draw that web content includes anything that is rendered by user agents, like HTML and SVGs.
Why ATAG matters#heading-1
Better accessibility of content tools is critical for three reasons:
- Everyone should be able to create content for the web, regardless of disability.
- Authoring tools are in between the user and the HTML they create.
- The authoring tool can have the unique ability to prevent inaccessibility.
Let's look at these reasons in a little more detail.
Content creation is for everyone
‘The web is for everyone’, as web inventor Tim Berners-Lee likes to say, applies as much to accessing websites as it does to creating them. His first browser had both viewing and editing capabilities, so clearly the web was always meant to be about both consumption and creation. Many of us love to create vlogs, set up online classes, publish recipes, tweet, make TikToks, create art… this should just work for people with or without disabilities. If content creation tools have barriers, that's everyone's loss.
The first web browser, “WorldWideWeb”, was also an editor.
In business, it would be illogical (and illegal) if you couldn't hire content professionals with disabilities, just because they can't use your content tools. In your company today, Harry from marketing might be able to use a mouse, but when he leaves his successor might only use keyboards.
Support for all of HTML
The second part to authoring tool accessibility is their ability to output accessible content. Imagine two tools to create bulleted lists. One does this with divs and images of bullets, the other uses the standard ul and li elements. The latter is what we need, and not just when dealing with lists, but for all kinds of markup:
tableswithcaptionsvideoswithtrackelements andmutedandautoplayattributesfieldsets withlegends- images with
altattributes - translated content with
langattributes
Not all tools let you create all or these structures, at which point they basically become the accessibility issue.
Authoring tools as accessibility assistants
Even cooler than outputting sensible and appropriate markup, authoring tools could provide hints. They could try to be a helpful “accessibility assistant”, by point our potential barriers when they notice you're creating them. For instance, if an authoring tool lets you pick a foreground and background colour, it could warn you when you pick two colours that have insufficient contrast.
ATAG recommends various ways of assisting with making content more accessible: accessible default components and templates, solid documentation and, as described above, suggestions and hints.
Who meets ATAG#heading-2
At the time I am writing this, I am not aware of any authoring tools that meet 100% of ATAG, as in, all criteria at level A or AA. That doesn't mean all is lost, every bit helps and there are a lot of authoring tools that meet many bits of the standard.
With the ATAG Report Tool, people can create a report with specific details about which parts of ATAG they do or do not meet.
As described above, there are lots of good reasons to try and meet ATAG. It is a worthwhile pursuit for authoring tool makers and a worthwhile request for procuring departments to put in tenders.
What's in ATAG#heading-3
There are two parts to the ATAG standard:
- editing experience (part A): does the tool work for people with disabilities?
- output (part B): does the tool output accessible content?
If you're still with me, I'd like to describe ATAG in a bit more detail. Like WCAG, ATAG has Principles, Guidelines and Success Criteria. In the following sections, I will discuss the Principles and Guidelines in my own words. Full and official wording is in the ATAG 2.0, published by the W3C. This is not legal advice.
Authoring tool UI meets accessibility guidelines
- Web-based functionality is accessible:
The full editing experience conforms to WCAG 2.0 or other accessibility guidelines. (A.1.1) - Non-web-based functionality is accessible:
The interface conforms to platform-specific accessibility guidelines. (This one specifically applies to authoring tools that are not web-based, which was more common when ATAG came out) (A.1.2)
Editing UI is perceivable
- Alternative content available to editors:
If there is anything visible that is not text, like icons, images or video, there is alternative text available. (A.2.1) - What's indicated visually in the UI can be programmatically determined:
Status indicators (like changes or spelling errors) and text properties (like italics or bold) are conveyed to users of assistive technologies. (A.2.2)
Editing UI operable
- Works with keyboard:
Everything that can be done with a mouse, can just as easily be done with a keyboard, including drag and drop and drawing capabilities. There should be no keyboard traps. Keyboard usage should be efficient and easier to use than just with sequential access (for example: use WAI-ARIA landmarks or offer keyboard shortcuts). (A.3.1) - Enough time:
Time limits in the editor, like for auto-save, can be turned off or extended (some exceptions apply). (A.3.2) - Flashing content optional:
Flashing content, like videos, including previews of that kind of content, can be paused or turned off. (A.3.3) - Content can be navigated by structure:
Users can navigate quicker by structure, for example headings, lists or HTML elements. (A.3.4) - Content searchable:
Users can search in text content, results are focused when shown. If there are no matches, this is indicated. User can search in two directions (backwards and forwards). (A.3.5) - Supports display preferences:
If there are user settings for display, this only affects the editing view, not the output. If a content editor uses OS settings like high contrast mode or their own stylesheet, this does not break the editing experience. (A.3.6) - Previews are accessible:
When the tool shows a preview of the content, that preview is at least as accessible as in current browsers and other user agents. (A.3.7)
Editing UI is understandable
- Helps editor prevent and correct mistakes:
The tool lets users undo changes and settings. (A.4.1) - (Accessibility) features documented:
The tool has documentation for all features, including accessibility features. (A.4.2)
Fully automatic processes produce accessible content
- Generates accessible markup:
When the tool generates markup, that markup is accessible. If accesssibility information is required, like alternative texts, the content editor is prompted to provide that information. (B.1.1) - Preserves accessibility information:
If content is pasted from a word processor or converted from one format into another, any accessibility information is preserved. (B.1.2)
Supports producing accessible content
- Accessible content production is possible:
If some options produce more accessible content than others, they are displayed more prominently. If properties and attributes can be set, those relevant for accessibility can also be set. (B.2.1) - Editors guided:
Editors are guided to produce accessible content. (B.2.2) - Text alternatives can be managed:
There is a tool for providing text alternatives to “non-text content”, like images, videos and data visualisation. (B.2.3) - Accessible templates available:
There are accessible templates available. If there is a repository of templates, it is easy to find the ones that prioritise accessibility. (B.2.4) - Accessible components/plug-ins available:
If any components or plugins are built-in to the tool, they are accessible. If there is a gallery of components or plug-ins, it indicates accessible options. (B.2.5)
Helps with improving the accessibility of existing content
- Checks accessibility automatically:
Has built-in checks for common accessibility problems, for example a check to identify missing alternative text. (B.3.1) - Helps content editors fix problems:
Provides suggestions to content editor about accessibility problems. (B.3.2)
Promotes and integrates accessibility features
- Accessibility features prominent:
Accessibility features are on by default and a prominent part of the editing workflow. Documentation shows examples of how to create accessible content, for instance with example markup or screenshots. (B.4.1) - Documentation promotes accessibility:
The tool provides suggestions to content editors about accessibility problems. (B.4.2)
Wrapping up#heading-4
In summary, ATAG recommends two things:
- a fully accessible authoring tool interface (basically, one that meets WCAG)
- the possibility to produce accessible “web content” and help with that in the form of documentation, default templates and suggestions
The instructions are more detailed in the standard, but that's what it comes down to in most cases.
Though the standard is only met at most partially by most tools today, a wider landscape of ATAG-supporting tools would be fantastic for web accessibility (because it's easier when you do it earlier). Increasingly, authoring tool makers start to realise this and that is wonderful.
Comments, likes & shares (108)
John D. Jameson, Vicent Sanchis, Simon R Jones, Sonny.css, Johannes 👻, Vinay Raikar, Dr. Viviana Menzel 🕊, Gabor 💗, Florian Geierstanger, Scott de Jonge, Dave Wallace, Kitty Giraudel, knut, Bhupesh Singh, BH, Markus Schork, 'Chaals' Nevile, Charlie Turrell, Kiran Sonley, kev e, WebOverhauls.com, Ruth, 🇺🇦Jennifer Strickland (they/them), IamAllynIam, Joe Lanman, Steve Lee, nic, JulieG, Benoît Launay, Lizzie Bruce, Dennis Lembrée, Gift ✨, Ville V. Vanninen, Uzoway🚀, Peter Grucza, Nick Dunn, Cyril (he/him), Alicia Jarvis (She/Her/Elle) 🇨🇦🇺🇦🌻, Ofer Shaal, John Lockhart, Johnson🚀, mashbooq, Tyler Sticka, Diana Thompson :wordpress:, Alistair Shepherd, Sarah E Bourne, Manuel Matuzović, Morbi, Philip Zastrow, Tyler Sticka, Joachim, westbrook, Tobias Zeumer and notsoloud liked this
Amelia Bellamy-Royds, Kevin, Vicent Sanchis, Dennis Lembrée, Dave Wallace, knut, Bhupesh Singh, Ronalene White, Chauncey McAskill, Gift ✨, Alicia Jarvis (She/Her/Elle) 🇨🇦🇺🇦🌻, Tamás G, Darrell Hilliker, meduz', Daniela Kubesch, Manuel Matuzović, Cory Dransfeldt :prami:, Philip Zastrow, Curtis Wilcox, Svenja, DNKrupinski, Joachim, westbrook, François Nonnenmacher, Sandra Pilz, Bhupesh Singh, Orangenoel and Tobias Zeumer reposted this
A couple of weeks ago, I joined the Fronteers Jam Session to talk about something that I’ve been working on in the last couple of months: the ways in which CMSes can bring accessibility benefits. This is a written version of that talk.
Note that these are just some examples of things that CMSes can do… truth is, I only had ten minutes. But still, I’m hoping more people will think of CMSes as accessibility accelerators, as there is lots of potential!
From one block of content to lots of content blocks
As an industry, we have gotten a lot better at designing content on the web since the early days. Away are the times of boring looking documents with little white space and ineffective typography.
Part of why we got better, is that modern CSS has gotten some exciting new features in recent years. We now have things like variable fonts, HSL colours, blend modes and floats that are not rectangular. And of course, there’s this now widely supported new lay-out mode: Grid Layout. It lets us be intentional about white space. We can lay content out in ways that we truly did not have before.
Something else that has changed is how we thing about what we are designing. Thanks to the work of people like Alla Kholmatova (Design Systems) and Brad Frost (Atomic Design), we have, as an industry, started to think about our work in terms of components or patterns… distinct pieces of functionality, rather than full, all-encompassing pages.
This leaves us with a new content management challenge. Previously, these long documents could be edited with one big block of WYSIWYG-text. Components require something different, you would probably create fields for every bit of data they contain.
A teaser component might have fields for a title, sub title, call to action text and link destination, for instance. For front-end developers, that might mean you can have all this data as strings, and wrap it in whatever HTML makes most sense. This isn’t necessarily new or recent, many CMSes have had this option for years, and it is has become the standard in headless systems. But still, many large organisations don’t.
There is also a different content management trend that addresses our new component-based world: visual editors. Or, as they’re sometimes referred to: “no code editors”. This might sound worrying to all front-end developers, because when you wrap markup around data, you can do all sorts of good for performance, code quality and accessibility. Having a system deal with all of that automatically is… scary? And what about accessibility specifically, what if this harms actual users?
I could turn this question around… what if CMSes benefit actual users, by having accessibility built in?
The accessibility standard for CMSes
Accessibility standards consider CMSes as part of a larger group, that also includes other tools, like Learning Management Systems (LMS), wikis, social media, WYSWIYG editors, ”Save as HTML” functionality… basically everything that creates web content or facilitates the creation of HTML. These tools that create web content are also known as authoring tools. They can potentially improve a lot of accessibility at once.
Among a number of standards and specifications, the W3C has published three standards for web accessibility (“Accessibility Guidelines”):
So yes, there is a standard specifically about the accessibility of authoring tools, including CMSes and other things that produce HTML (see also: ATAG: the standard for accessibility of content creation).
There are two things that ATAG requires from CMSes: they should be accessible themselves (i.e. work for people with disabilities), and they should encourage accessibility (i.e. produce and assist content editors with producing accessible output).
The editing experience
Creating an accessible editing experience means that people with disabilities have no barriers to create content: they can use the buttons, understand relevant context and access the interface with the input method that works for them.
To give some examples, and yes, these also exist on websites that are not CMSes:
Accessible names A common accessibilitity issue is that the buttons in the interface are visually just icons. To make those work for users of assistive technologies, it is important that they have proper labels or accessible names. More about this in Naming things to improve accessibility Keyboard accessibility Something else that is common in CMSes is that they require a mouse to be fully used. By ensuring keyboard accessibility, you can make the interface work for various groups of people. This includes indicating what has focus. See also: Indicating focus to improve accessibility Zooming Some users will be using the CMS interface with their screen set to zoom in considerably, say 200 to 300 percent. This works well in the type of text documents I discussed at the start. On the web, text just reflows. It becomes more tricky in complex CMS interfaces, because there could be floating and sticky things that overlap with content when zoomed too much. See: Test content scalingAn interesting overview of what accessibility issues could look like in a real CMS is the crowdsourced accessibility audit that was done for WordPress’ new Gutenberg editor. As someone who is interested in the accessibility of content management systems, I am grateful that this was released publicly, this way everyone can learn.
The output
Apart from breaking barriers in the editing experience, we can also break barriers for users of the actual website. If we improve how HTML is produced by a CMS, we can potentially make a difference for all pages and sites produced by it.
Alt attributes
Most front-end developers will be aware images require alternative text in their
altattribute (or a conscious decision to leave it blank). Yet lots of websites lack it on some of their images. I don’t think this is because people aren’t aware of what thealtattribute is for. This could simply be a responsibility issue: the developer only built the template, the content editor only used the template, etc… Somewhere in between the attribute did not get shipped to the user.The CMS could be smart about this. It could:
alt(becausealtattributes can become link texts)Spelling
If you’ve accidentally used “Swbmit” as a button text, that might not impact visual users so much, as they will probably see from the visual context what the word should be. For someone using a tool like Dragon NaturallySpeaking, which lets users tell their computer which buttons to click, the mismatch could be more problematic. For someone who uses a screenreader, it could also be annoying to have misspelled content, because if it is misspelled, it will get mispronounced , too.
What if the CMS had a built-in spelling checker? That way, we could identify issues before they exist, and fix them before they get shipped to the user.
Colour contrast
When your site uses that design pattern where there is a text layed over a photo, it matters a lot what the photo is. Is it a dark-ish photo with light text on it, or are text and photo both light? The latter could lead to super low contrast, and with that, barriers for all sorts of users. This can affect people with various kinds of visual impairments, but also people who are outside in the sun, or those who have turned Brightness on their phone down to safe battery life.
Colour contrast issues can be programmatically detected, so why not do it right in the CMS? After uploading a new header image, the CMS could do a quick contrast check and display an error if the page no longer meets the criteria. Again, we could identify issues before they exist, and fix before shipping.
Whether it be with automated checks, carefully crafted content editing screens, extensive documentation of accessibility features… if we manage to bring some of our accessibility fixing to the CMS, we may be able to prevent barriers from shipping to users.
Conclusion
As front-end developers, we are all involved in the creation of web content. With this post, I hope to have given some examples of how CMSes can help create more accessible web content. Of course, it is just a couple of examples… but I think there are CMS-based solutions like this for a lot of different accessibility problems that we see on the web today. To be continued!
I'm so happy about what Interop 2022 is doing for web compatibility in general. It made me think: what if we had something similar, but accessibility-specific, focused on compatibility between our code, assistive technologies and browsers? Excitingly, ARIA-AT pretty much has that goal.
Interop 2022 is great
In the Interop 2022 effort, all major browser vendors, browser engineers and other stakeholders agreed “to solve the top browsers compatibility issues identified by web developers” in one year. I danced a little when I saw that. I mean, they align their priorities between them and web developers get a say in what the priorities are. Excellent.
Subgrid,
<dialog>andscroll-snapare tremendous features, but consistently cross-browser supported subgrid,<dialog>and scroll snap (and more) are the real deal. Because browser compatibility issues can be quite the nuisance. They make web development harder and more expensive. Web developers end up with a choice between either supporting less browsers or adding hacks and more bloated code. Either option likely trickles down to the experience of end users.Unrecommendable web platform features
As an accessibility specialist, I spend some of my time giving advice on how to code accessible UI components. From time to time, I want to recommend a thing, but I don't, because of bugs or inconsistencies somewhere between browsers and assistive technologies.
I asked on Twitter what people's top issues were:
Some responses that came in, all browser focused:
aria-controlsis not or weirdly supported by screenreadersdetails/summaryis not communicated to users of screenreaders in Firefox if the arrow is hidden (as documented by Scott O'Hara in The details and summary elements, again). That's a problem: conveying status to assistive technologies is a core feature of functionality that does visual expanding and collapsingaria-ownsis not supported in Safari (see also: Diego Haz' demo)Having these issues open for so long hurts web accessibility:
On Twitter, people also replied with other interesting ways browsers could improve accessibility, like a browser implemention of “skip to
<main>” (as Léonie suggested) or even to any landmark (as Curtis said).And then there are issues around what browsers do, but (some) accessibility specialists disagree with, like that
<dialog>'s focus trap can escape to the browser chrome. I've heard from developers whose accessibility consultants recommended them not to use<dialogin the first place and that's an issue.I believe in personal responsibility when it comes to building a more accessible web. Teams need to test their work and ensure accessibility. But at the same time, change in the primitives (like browsers and CMSes) is needed and can improve a lot of accessibility at once. All of the above issues are most easily solved by browsers, not individual web developers (see also my earlier post, More accessible defaults, please).
ARIA-AT
If we look beyond just browsers and focus on assistive technologies, an interesting project comes to mind. The W3C's ARIA-AT Community Group has the goal to ensure “assistive technologies work with web code in predictable ways”. The group works on interoperability in four ways (taken from their homepage):
The ARIA-AT explainer video explains why this is so important: “there are hundreds of interpretation issues between screenreaders,” and “the way screenreaders and browsers interpret web code changes all the time”.
I am very excited for this project, it will be super cool to see the test results pop up in places like the ARIA Authoring Practices Guide.
Summing up
It would be great for the web to see browsers prioritise accessibility bugs and align between them on the accessibility aspects of current features like
<dialog>,<video>, form validation andaria-controls. Either as part of the regular Interop program, or separately. At the same time, returning to the question I started with: yes, more interop between assistive technologies would be very welcome. Improving how assistive technologies interpret our code is a fantastic goal—I'm excited for the impact ARIA-AT will have.The Authoring Tool Accessibility Guidelines (ATAG) are guidelines for tools that create web content. While reviewing this week, I wondered if the Text Search criterion (A.3.5.1) is met as soon as users can use browser built-in search. You know,
Ctrl/⌘ + F. Turns out: yes, if the tool is browser-based and the UI contains all the necessary content in a way that CTRL+F can find it.Let's look into a bit more detail. The criterion requires that text content in editing views can be searched:
(From: ATAG 2.0)
True accessibility depends on a combination of factors: browsers, authoring tools, web developers and users—they can all affect how accessible something is. ATAG is about authoring tools specifically, so my initial thinking was that for an authoring tool to meet this criterion, it would need to build in a text search functionality.
However, reading the clauses, it sounded a lot like what
Ctrl + F/Cmd + Fin browsers already facilitate. Great news for authoring tools that are browser-based (sorry for those that are not). Browser built-in search finds all visible text in a page (as well invisible text in details/summary browsers), matching results are presented, “no match” is indicated and search works two ways. It doesn't find alternative text of rendered images, but if you have text input for alternative text, it finds the contents of that.details/summarycontains the word you search for, it goes to open state (this is per spec, but Firefox and Safari don't do this yet)Note: in screenreaders, the experience of in page search is not ideal. I have not tested extensively and am not a screenreader user myself, but quick tests in VoiceOver + Safari and VoiceOver + Firefox indicated to me that one can't trivially move focus to a result that is found and “no match” is not announced, it needs cursor movement to find. This seems not ideal, but again, I am not a screenreader user and may be missing something.
All in all, the in-browser seems to satisfy the requirements. Lack of matches is indicated (though not announced) and matches can be given focus (though the browser doesn't do it; not sure how that would work either as the matches will most likely not be focusable elements so that would be a bit hacky and it would not solely have advantages). These caveats are accessibility issues. I feel they'd be best addressed in browser code, not individual websites/apps, so that the solution is consistent.
Ok, so if the browser built-in search meets the criteria, let's return to the question I started with: should an authoring tool merely make sure it works with built-in search, or should it implement its own in-page search?
The unanimous answer I got from various experts: yes, in this case the browser built-in is sufficient to meet the criterion. It also seems reasonably user friendly and likely better than some tool-specific in-page search (but note the caveats in this post, especially that all alternative text would need to be there as visible text). Of course, most authoring tools have more search tools available, e.g. to let users search across all the content they can author. In today's world, they seem like an essential way to complement in-page search, especially as a lot of authoring tools aren't really page-based anymore.
Many thanks to Sara, Jutta, Chaals, Michael and Eric for pointers, help and answers regarding various parts of this post.
@hdv Thanks for the tip. I haven't dug into ATAG yet. Seems like a good time to do so.
@hdv Agreed! Asking questions like this during the sales process will make its way to product/engineering backlogs. Great idea.
Today I was at the IAAP-EU event in Paris, where we spent a morning workshopping and clarifying parts of EN 301 549, the procurement standard that is used in the Web Accessibility Directive.
I managed to get a spot in the group that focused on 11.8, the part of EN 301 549 that focuses on authoring tools. In this post, I'll share some insights from that session.
This post was written, as always, in personal capacity. And sorry, I don't have an HTML link for EN 301 549 (there isn't one currently, but there is a PDF).
What actually are authoring tools?
When my job was to promote the use of ATAG, I used to say authoring tools are “tools that create web content”. In EN 301 549, they are defined more broadly, beyond web:
(from EN 301 549, chapter 3: Definition of terms, symbols and abbreviations)
In other words, this definition includes web content as well as non-web content. The EN defines “non-web content” as “not a web page, not embedded in any web pages or used in the rendering or functioning of the page”. Examples of such content includes PDFs, Word documents and EPUB files. There's also a W3C document specifically about accessibility of “non-web content”, WCAG2ICT (which is informative, not normative) .
EN 301 549's authoring tool definition is followed by three notes, that all demonstrate the extent to which these tools exist:
In our group we quickly realised that there are indeed a lot of different authoring tools. The most obvious one is Content Management Systems (CMSes). Others that people mentioned are social media, online forums, video editing tools, WYSIWYG editors, and email clients. ATAG at a glance also mentions Learning Management Systems, blogs and wikis. It's a broad category, there are a lot of tools that can make (web) content.
The ATAG reference
ATAG, the Authoring Tool Accessibility Guidelines, is the standard that provides recommendations for both making authoring tools themselves accessible (part A), as well as the content they produce (part B). See my earlier post ATAG: the standard for content creation for an overview.
Conforming with EN 301 549 requires that all of our web pages meet all of WCAG (up to Level AA, see EN 301 549, clause 9.6). But it doesn't require ATAG. ATAG is merely mentioned as something that is worth reading for “those […] who want to go beyond [EN 301 549]” (in 11.8.0). In other words, there is no normative requirement to read it, let alone to apply it.
Still, some CMSes do. For instance, Drupal supports ATAG (part A and B) from version 8. Joomla, Wagtail and Craft CMS also have done a lot of work towards improving accessibility, see the W3C's List of authoring tools that support accessibility.
However, that doesn't mean ATAG isn't an incredibly useful standard for people who make and use authoring tools. In fact, it is. In 11.8.2 to 11.8.5, some ATAG requirements are explicitly added. These clauses are requirements, because they use “shall”, which in ETSI standards implies a “mandatory requirement” (say their drafting rules).
Note: that EN 301 549 requires these things, doesn't mean the law in European countries does. These laws often refer to specific parts of the EN, or refer to EN 301 549 specifically in relation to web content.
Note 2: clause 48 of the Web Accessibility Directive is interesting. It includes various points I'd love to see member states adopt:
11.8.2: “enable” and “guide”
Out of the authoring tool requirements, we talked most about 11.8.2. It says:
The key words to me are enable and guide. My personal interpretation of what that means, and maybe partially what I want it to mean:
What I like about the “guide” part especially: it addresses problems where they surface first. It lets authors fix accessibility problems before they ship to production, if the authoring tool guides them.
Other requirements
We didn't get to the other clauses, but they are interesting too:
Summing up
It was fun to dive into one of the requirements specifically, and my hope is for two things. First, I'd find it useful for there to be more extended guidance on these clauses. They are fairly minimal and more concrete examples would help. Second, the testability could improve. What makes a template an accessible template (one that meets WCAG?), what sort of assistance is sufficient, and what sort of “guiding the author” is? And then my last open question would be: when does an authoring tool fall into or outside of the scope of the organisation trying to comply with EN 301 549? Is this when they use an authoring tool or only when they create one? To be continued!
List of updates- 11 April 2024: Fixed typo “WordPres” and added links to WordPress accessible themes and Drupal list of modules that support accessibility. Added link to Web Accessibility Directive, clause 48.
Thanks to Eric Eggert and Susanna Laurin for answering questions I had when writing parts of this post, and Wilco Fiers for leading the workshop.