Out of the authoring tool requirements, we talked most about 11.8.2. It says: Authoring tools shall enable and guide the production of content that conforms to clauses 9 (Web content) or 10 (Non-Web content) as applicable. 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: enable: that tools have, for all types of content they can produce, functionality to create any necessary accessibility aspects for that type of content. For instance, if they let you add an image, they need to let you add a text alternative. There's a lot of grey area, because some very complex images might require linked descriptions that don't fit as alternative text. And what about types of content that the tool creator users aren't supposed to create? LinkedIn might say it only lets users create plain text with links, not headings. Is the fact that users will try and add faux bold text and whitespace instead of headings LinkedIn's fault or the user's? guide: that tools tell authors about accessibility issues and help them get it right. I would love for more authoring tools to do this (see also my pledge in Your CMS is an accessibility assistant). Let authoring tools guide authors to more accessible content, this should have a large multiplier with fewer barriers across the web as a result. 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.

European political parties seem to be neglecting their obligation to provide information to all voters, whether they have specific access needs or not. In doing so, they are creating a barrier not only for persons with disabilities but for the democratic process itself.

Some website owners had actively removed code that benefits users, thereby deliberately making the interface less accessible.