Your CMS is an Accessibility Assistant

Transcript

Ahmed: Hello, everyone. Welcome once again to WordPress Accessibility Day 2020. My name is Ahmed Kabir Chaion, and I’m working as a business development manager at weDevs. I’m also a regular contributor to the making WordPress documentation, design, polyglots, accessibility, hosting, community, learn WordPress, and marketing. I will be your host for this session. You’re here for the 8 a.m UTC talk with Hidde de Vries. Please feel free to add your questions to the YouTube chat, and we’ll answer those at the end.

Your content management system plays a decisive part in creating accessible content suggest the Authoring Tools Accessibility Guideline – ATAG. Whenever a content designer creates content the CMS could help with the accessibility of it. For instance, when a designer drops in an image, the CMS could point to the ideal text alternative or calculate the consequences for color contrast. In this talk, you will learn more about what ATAG is and how, with ATAG in mind, CMSs can personally assist content editors on their way to a more accessible website.

The speaker for this talk, Hidde, is a web developer and accessibility specialist at the W3C’s Web Accessibility Initiative, or WAI based in Rotterdam, Netherlands. As part of the WAI guide project, he works on the accessibility of authoring tools like CMSs and website creators, and guidance that supports the Web Content Accessibility Guidelines – WCAG. He has over 10 years of experience working as a freelance front-end developer and accessibility person for organizations like Mozilla and the Dutch government. On his blog he writes regularly about reusable components, CSS, and web accessibility. Which brings to the session “Your CMS is an accessibility assistant.” Take it away, Hidde.

Hidde: Hello, this is Hidde, and I’m here today to talk about how your CMS could be seen as an accessibility assistant, and how that can help organizations, including maybe the clients, or the users of a CMS. Very briefly about myself, I work as an accessibility specialist at the W3C, the World Wide Web consortium, where i worked at the Web Accessibility Initiative.

We have a website which I’d like to plug. On our website there is loads of information about web accessibility, about planning, designing, developing, testing, advocating, and training for web accessibility. So many people don’t know about all these amazing resources that are on this website, um, so I thought I’d mention it. But disclaimer I, I do work on some of the content for this site.

Now, I focus mostly in my work on authoring tools. And authoring tools, if you’re not familiar with that phrase, they are tools that create web content. And with that, as probably won’t surprise you, they are also tools that can improve a lot of web accessibility at once. That is a very exciting prospect, I think, and I’ll be talking a lot today about how we can, can make that a reality. How can we really employ authoring tools to, to improve accessibility in, in many places at once. Now, first let’s look at a couple of examples of authoring tools.

We’re talking about things like WYSIWYG editors, course creators, learning management systems, or anything that they use in online education – very important in times of COVID – content management systems, of course, wikipedia, your “save as html” functionality, social media, form generators, site builders. Lots of these, these different things, all have in common that they create content for the web, or that they they provide some sort of interface for their users to create something that will ultimately live on the web.

Now specifically about CMSs – we’re at WordPress Accessibility Day – you can think of the authoring tool as the CMS itself. And I imagine some people watching this today work, work on WordPress core, or have provided some patches for it, or maybe considering contributing to WordPress, but others may be working on plugins like form builders, custom field managing stuff, things where you can manage events, or social media, cookie banners, even. Just anything that you can plug into a website, and that will also create web content, it will also be considered as an authoring tool. When I talk about CMSs in this talk, I very much also mean plugins and themes, as well.

Now, the web is meant to work for everyone. That is a point that we take very seriously at the W3C. This is a photograph of Sir Tim Berners-Lee, the inventor of the web, who was at the opening ceremony of the London Olympics in 2012. And he made these four words appear. “This is for everyone.” Now I think and I haven’t, you know, I haven’t checked this with him personally, but I think you could interpret this in various ways.

One is that the web should be available for, for everyone to, to kind of get onto the web. So, of course you need to get a cable subscription, or go to a library, and maybe pay to use a computer. But, ultimately, the web is available for everyone – this is for everyone. Secondly, I think everyone can have a website on the web, as well. You don’t need to apply for permit at your local government, or something like that, or you know do, do something very special. You need to have a web server, or rent one, and you can put some HTML on there and make it available on the URL. So, in that sense it’s also for everyone. And, and the third way that you could read this, “this is for everyone” is as, this is something that should work for everyone, including people with disabilities. And that is the definition that we use at, um, at WAI.

Making the web work for people with disabilities is what web accessibility is about. We’re, we want to make sure that this is for everyone. Now, to that extent at WAI, we have three web standards that are about the accessibility of, of web content, ultimately. Now, many people will be familiar with the WCAG standard, which stands for the web content accessibility guidelines, but there’s two more sets of guidelines, that are very closely related, and that together really create that picture of an accessible web. So there is, uh, the web content accessibility guidelines about web content itself, but what about the software that people use to access web content? Browsers, or user agents. There’s a specific center for that, the User Agent Accessibility Guidelines – UAAG. And what about the software that creates that content, authoring tools?

And for that we have the Authoring Tools Accessibility Guidelines.

So together, these three standards, they all say something about the accessibility of web content. About the content itself, about the software we use to view the content, and about the software we use to create the content. Now authoring tools are very important, and CMS is with that. They’re essential in this picture of web accessibility. Because if we get it right, if we get it right in authoring tools, we’ll be able to include more content creators. We can have more people publish stuff on the web. And the second reason that I think authoring tools are so important and exciting, is that content creators may be allowed to fix accessibility problems before their website goes live. It is the central central theme of what I, what I want to say today.

Now the standard for authoring tools, as I said, is ATAG. With the latest iteration ATAG 2.0. Now, in ATAG, and I’ll talk about a lot of ATAG today, but if you want to read it at your own pace you can visit the source called “ATAG at a glance.” It’s a page that has a bulleted list of the main points that are in the ATAG standard. So that is something you could review at your own pace. But today we’ll also go through a bunch of different guidelines that are in ATAG – success criteria – and I hope to give you a good overview of what you can find in ATAG and how it can really help end users and people who edit content on the web.

Now, the ATAG standard consists of two parts. The first part is about the editing experience, so the content editing itself, the, the backends for example, and the second part is about the output of content. I’ll focus mostly on output today, but also talk a bit about what we can do to improve the editing experience for people with disabilities. Yeah, let’s look at that first. So, part A of ATAG is about the accessibility of the editing experience. So the very first success criteria, on A.1.1.1, is about making sure that your interface conforms to the WCAG standard.

And part of that, of course, is making sure that your interface works with text zoom. It’s something I heard a lot from users, uh, when I talk to them for my work. It’s when they zoom in the interface they are, it’s not as easy for them to use the interface, or sometimes the interface becomes completely unusable. So testing with text zoom is one thing you can do. Text alternatives for icons. It’s very common these days to have interfaces that consist of just icons. So, if you work on the, on a plugin, or a theme, or something that has an editing interface where icons are the main thing you click on, make sure that there are text alternatives for them, so that there’s an accessible name somewhere in the source code.

Make it work with a keyboard is another great advice. And that includes things like visible focus, so that you can see, at all times, where you are on the page, before you interact with something, and that you can use all controls. So that includes all form fields, anchors, and buttons. Another recommendation in ATAG is about displaying previews accessibly. Because most content management systems, or authoring tools in general, plugins as well, will have some way to preview the content that you’re working on.

And this material is about making sure that that content is accessible, as well. Or you can think of things like helping with spelling. Some people may have dyslexia – they’re editing some content – you can help them a great deal by helping them correct their spelling. Now, that’s a bit about the first part of ATAG, improving the editing experience.

But what I really promised to talk about today is how your CMS could be an accessibility assistant, and, in that sense, support the production of accessible content, as the official name is for part b of ATAG. And for that, let’s talk a bit about what accessible content is.

It is things like that you have tables with headers. That you have forms with the appropriate labels. That you have hero images with plenty of contrast. That videos are captioned. That you can have multilingual content with the right language attributes. That everything is nested according to specification. That carousels can pause, and that you have sensible heading structure. So all of these things, they contribute to, to more accessible content. So for your end users, for the people using the website or, you know, web content that you’re creating, all these things need to be in order.

So if we want to have a good accessibility assistant, it should assist with all of these different things. And usually they could be different, different products, right? Because sometimes you might have a plug-in specifically for creating tables, or one specifically for creating forms, so they could be specialized products that focus on these specific tasks. And an accessibility assistant would, of course, help avoid inaccessible content. So it would avoid things like tables with no headers, it would avoid things like form fields that have no names, illegible text, caption-less videos, multilingual content that doesn’t have the right lang attributes, non-standard nesting, carousels that don’t have a pause button, and headings for the wrong reasons.

So, a CMS that really helps you get your accessibility right will, maybe, warn you for these kinds of mistakes, or it will generate markup that doesn’t have these problems, and, and provide templates that comes with with the right stuff. So that’s what this is all about. We want to avoid inaccessible content for our end users ultimately, and we want to help the people that are using our products, like our CMS, or our plugin, or our theme. We want to help them avoid inaccessible content, so that they can ship a website that is accessible and find problems before they ship it, ideally. So a great CMS can really help content managers make their content more accessible.

Think about things like when content is created, it is accessible, which is the success criterion 1.1.2 – B.1.1.2 in, in the ATAG standard, and that is about things like, you know, you need to make sure that it’s nested according to the standard, you want to make sure there’s no empty links inside of this content. Sometimes, to make content accessible, you need some more information.

So maybe you need to prompt the user for required accessibility information, like a caption for table, an alternative text for an image, or for video, those sorts of things. You, you need to prompt for, if you know that, that could cause an accessibility problem. and, you know, you rely on the content editor to provide the information, you’ll need to prompt for it. So, uh, captions for tables, alt text for images, and labels for form fields, are just some examples of things that you could prompt for.

Or when content is generated, maybe there could be automated accessibility checks. Or if it can only be checked manually, maybe the tools could suggest to the user to do a manual check. For instance, if it’s about the heading structure of the page, or if it is about text alternatives, maybe they are centrally managed, and you want the user to make sure that the text alternative makes sense for this specific use case.

For instance a photo of a speaker, but their name is also in the content, so maybe at that point you would want a zero, or you would want an empty alternative text, rather than repeat the name of the speaker, so that sort of thing, that requires a manual check. Someone who knows the content and understands it to, to go through it, and as an authoring tool, as a CMS you could actually provide the right instructions and help the the user to figure out how to make their content accessible.

2.1.1 is about allowing to create accessible content. So, not everyone realizes this, but there are a lot of authoring tools out there that don’t provide, or don’t allow for entering accessible content. For instance, if you upload a video, if there’s no caption it isn’t accessible – but if your video widget doesn’t have a caption button, then you know the user cannot create an accessible video with your authoring tool. Or if there’s no alternative text option. And some social media. for instance. only recently added the option to add alternative text. And there is a bunch of social media out there that still don’t have that option available. So even if users want to create accessible content, they are not able to, because there’s no option for alternative text.

So, for image fields, that means there should be an alternative text field, and for video players there should be an upload button for captions. And this is specifically important for those creating plugins that deal with video or, or images. Make sure that people can manage their alternative text, so that they can create accessible content in the first place.

Something else that ATAG recommends is to have accessible templates for the most common use cases, and to be able to filter for that. Um, I know there is a filter available in the, in the WordPress directory of different themes, so that is another important way that you can help content editors make the right decisions. And there’s a B.2.5.1, which says that you should provide accessible UI components. Or, as the specification calls it, “pre-authored content.”

So when you provide something like a carousel, or, or tabs component, and users can add that into the page, make sure that they are accessible by default, so that the content editor doesn’t need to do anything – it just ships as an accessible component. So it makes a lot of sense to spend time on accessibility if you provide something like a carousel tool, because everyone is going to use your plugin is going to have a more accessible website. So, it’s going to have a huge, a huge effect if you spend that extra time on on accessibility, for all of those end users, specifically.

So here’s some interpretation of B.3.1.1 which is, why don’t warn users when they introduce a color contrast issue? Say you work at an agency, and a designer has produced this beautiful header with a dark photo of a black cat with white text on top of it. It has perfect contrast, and it’s been checked according to the accessibility guidelines. This is good, it passes all the tests, but then someone decides to replace the photo with one of Korean food, in this case. And it is a perfectly valid photo – but it is very light, and the text is also light, so at this point, when we drop in this photo, we’ve introduced a color contrast issue.

And it’s possible to programmatically detect color contrast problems. And with that, you could provide a warning for the content author that something is going wrong here. You could say, well, there’s not enough contrast – maybe there should be background color painted behind this text to fix the problem, or in some cases a larger text, or a bolder font could be just enough to address the problem.

Something else that you could do is to add a spell checker to content fields. I have a button here that says “Swpmit,” which, I guess for visual sighted users, they might parse it in their head and see that it probably says “submit,” because the “w” looks so much like a “u,” but if you are trying to use some assistive technology, it’s going to be pretty tricky to use this button, and it’s going to read it out weirdly in a screen reader.

If you use something like Naturally Speaking, it’s going to be hard to identify the specific button. So if there was a spell checker, you could avoid these accessibility problems altogether. Something else that you could automatically do is report readability levels. And I think I’ve seen this in some SEO plugins, but it’s also very valid thing to do for accessibility, to make sure that the text is nice and easy to read. And you could have readability levels, uh, warn the user when they’ve added text that’s too complicated and maybe help them fix the problems there, as well.

Something else that the standard recommends is to provide accessible examples.

So if you work on documentation, you can do a great deal, as well, about accessibility of your CMS or plugin by making sure that all of the examples really help the user to get their accessibility right. Sometimes that means the stuff that maybe gets copy/pasted, really ensuring that everything there is perfectly accessible. Sometimes, it means providing the right guidelines. Like, you know, if you leave this field empty, there won’t be alternative text, so make sure you put something in there. Or explain, kind of, how alternative text works.

So it’s really putting in an extra mile and making sure that the example is, is accessible and really encourages good accessibility.

So, basically, a good CMS can encourage more accessible content and help people get their accessibility right. Now, I’ve talked about the standard quite a bit, but I think one of the exciting things about authoring tools that help with accessibility is that it can really help with your process. Let’s look now at when, in the process, authoring tools can help. Now process is a bit of a tricky subject, I think, because whoever you talk to, depending on their organization, they will have different ways of organizing their projects.

Now this is an example of a process that your organization might be following, if it follows the waterfall principles. So you might start with some planning and strategy sessions, and do interaction design and visual design, then development and QA, then launch. You might have a process that is much more multidisciplinary, so you might have all the disciplines working together in iterations, and that could be a thing in sprints or doing something like scrum. Um, or you might be going back and forth between these phases. Like going back from launch, to strategy, or to interaction design, or sometimes maybe from QA to design.

Whatever you’re doing, I think there is a lot to say about where authoring tools fit into the process. For instance, if you’re working in planning and strategy, you can make a huge difference by choosing an authoring tool that supports accessibility in the ways that I outlined before. So adopting a lot of the principles in ATAG, and really helping the, the user to get their accessibility right, can really help in the long run, because if that’s the case, then later on in the process, it’ll be much easier for the organization to create webpages that are accessible.

In the interaction design phase, you could spend a great deal on how content should be authored in an accessible manner. You could test the authoring process with people with disabilities, if user testing is part of your your interaction design discipline. If you’re doing visual design, you could provide guidelines for customizing color, so that contrast works well. You could work on accessible examples, like large enough touch targets.

Uh, all these sorts of things, uh, can help you in a design phase, to make sure that anyone who’s authoring, uh, web pages later on, because you might not be designing every single web page – it might happen in the templating phase, and then content people might work with designs that were created. So providing some guidelines there can really help in the authoring phase.

When we’re talking about development, you could make a great difference by picking a theme that has accessibility support, or plug-in with accessibility support. Because, again, you’ll help people who create web content to do that in a more accessible manner, or sometimes get a lot of accessibility for free, if there’s a carousel component or something that was built accessibly.

When it comes to QA, you could embed automated accessibility tests in the authoring process. So, for instance, if someone creates a new page and presses save that there are some tests that are running automatically. If you have some test automation engineers in your team, take advantage of them, and let them help make the authoring process more valuable as well in terms of accessibility.

And then, when you launch, you may have something that is much more accessible than if you wouldn’t have done all those, those things, uh, because many websites are launched without much required for accessibility, sadly. That still happens. And those websites might find that they then hire accessibility consultants, get a big list of issues that they never thought of, and it might take them a lot more time to, to work through all of those issues. So if you start very much in the planning phase, and think about accessibility in all of these different phases – and I know that’s not a new thing, but I just want to say that that really makes a big difference.

And if you think of authoring in all of these phases, that can really help create much more accessible things by default.

Now it may be clear to you by now, that at WAI we find authoring tools are really important part of web accessibility. And to that extent we’re, you know, we’re doing a number of things to, uh, to improve the situation. The first thing is, um, I just wanted to mention that if the ATAG standard itself is a bit of a long read.

There is also the Implementing ATAG 2.0 document that has rationale and intent for each of the success criteria, and a bunch of different practical examples. And I’ve taken some of the examples in this presentation from there, as well. It helps to understand ATAG a bit better, if you you get stuck in in the main ATAG document.

Now, something that I’m involved with personally is something called the WAI Guide project. And one thing that we’re creating as part of that, to help people use the authoring process that I just outlined right, really putting authoring tools at the front and center, to help you get your accessibility right. We want to help people find tools that support accessibility.

So we’ve created a list of authoring tools where you can filter by ATAG criteria and find tools that support accessibility. Now this is all still dummy data that you can see here – it’s not live yet. But we are working on getting our first entries into the list, and you know, if you create a tool, uh, that you think qualifies for this, and has accessibility support, and that meets one or more of the ATAG criteria, do get in touch. I’d be interested to, to hear from you.

Um, at the same time, we’re also working on something called the ATAG Report Tool, where you can report on ATAG criteria.

So you can fill in some details, and then you go to each of the guidelines, and then you will say whether it passes or fails. And you can fill in some information about each of them. Now this is kind of on an optional basis, so each of these are optional. You can fill in the ones that you want to showcase, so if you particularly deal with one of the criteria well, then you fill in those, and maybe leave the others empty.

Of course we want to have as many criteria as possible, that will also make it easier for people to find your tool in our list, but yeah, we welcome reports this way as well. In this tool, you are able to create a report in JSON or HTML and you can also publish that on your website to showcase how well you meet ATAG. And, ultimately, you would be able to create a listing in the authoring tools list that we’re working on.

At the moment there’s not that connection yet, because it’s still in its early phases, bu,t yeah. Very much interested to hearing your feedback on this tool, as well.

Now, going to conclusions, uh, what I wanted to share with you today is very much that CMSs are essential for an accessible web. It won’t surprise you, as people who work on, on CMS’s and plugins, and maybe themes, even, but yeah, your work is very important for website, web accessibility. I hope this, this talk gave some more insights in more ways that it, that it does.

Now, secondly, I think CMSs should really help content editors get their accessibility right. And I open this talk about, like, the number of ways in which they, they can, so yeah. Hopefully, we can really see our CMSs as accessibility assistants, um, and that’s the question I want to leave you with: How would you turn your CMS, your plugin, your theme into a better assistant for web accessibility?

For now, thanks very much for listening. You can find the slides on talks.hiddedevries.nl. It is also, it’s also going to have all the resources, links, and video, ultimately, I think. Uh, if you have any questions, feel free to get in touch. It’s hidde@w3.org, or you can reach out on Twitter. Now I’m going to be showing off in a live Q and A right after this, so then I want to just thank you for listening, and shout out to the organizers of WordPress Accessibility Day. Thanks so much for putting this event on, and inviting me to speak.

Ahmed: Thank you so much, Hidde, with that presentation. We actually was able to learn a lot of things that are very, very important to choosing CMSs, and we have a bunch of questions. So, let’s just start with the first one, while a few more comes in. So, the first question we have for you is, “What would be the most important feature you must change in Gutenberg to be completely accessible? If you need to correct something, you could also do that.”

Hidde: Yeah, so I’m probably not the right person to ask, because I don’t work on, on Gutenberg. I think one very interesting presentation that would get you up to date with the latest on Gutenberg Accessibility is by Joe Dolson at the WordPress Campus. The video of that has recently been released, and I think that will give you a good overview of the stuff that that team is working on, sometimes struggling with, uh, sometimes really massively improving. So there’s, there’s a lot of work happening on uh, on Gutenberg, which I think is great. It’s hard to make a, an editor of the future, and also do it accessibly, so I admire the effort. I think it’s, uh, there’s lots of great work happening there, but I don’t have too much to say about the actual issues there.

Ahmed: Awesome. Next one is your suggestion if you know of any good tool for developers to test the different levels of accessibility – A, AA, or triple A.

Hidde: Yeah, so, those levels, they actually exist in multiple standards. So most people will refer to them when they look at the WCAG standard, that has these, these three levels: A, double A, triple A. The ATAG standard does as well. Now, for the UAAG standard, there’s a bunch of different automated test tools that try to interpret the rules that are in WCAG as test rules and, and run automatically.

Um, for, for ATAG those don’t really, uh, don’t really exist. Uh, so at the W3C we have this project called ACT rules, where we try to bring different tool vendors together, and work on, uh, test rules, harmonize those test rules, so that every tool kind of interprets WCAG the same way. Uh, I think that’s an interesting project to watch if you wanna, wanna know more about different rules that exist.

Um, but yeah, you can definitely test automatically for WCAG – that is good for if you’re developing a CMS, because one of the ATAG guidelines is conform to WCAG, so that’s, that’s good for the editing experience, but it’s also good for, uh, for the output. So if you check the the page that is being generated, or that the editor is working on, if you run that through some automated test tool, you might also be able to prevent some accessibility issues.

Ahmed: Great. So, the next question is one of my favorite, and this one asks why are we all focusing on WCAG and not also on ATAG – is there, uh, bias? Is there a priority when we’re choosing?

Hidde: It’s, it’s a great question, um, and something we noticed at WAI, as well, and, and kind of partly the reason why I’m now assigned to, to work on this. Uh, we would love more people to embrace ATAG and show the benefit of embracing ATAG, not just for people who make CMSs, or sell plugins, but also for the companies that buy them. We feel like there’s a unique selling point to be made because so many organizations are now required by law to be accessible. And if your tool can help them, you might be able to charge them more money.

So we feel like there’s a lot of benefit to, um, to looking at ATAG. It’s not happening, or it wasn’t happening so much, we see more uptake in the last year, and more people talking about it. We heard, um, Susanna talk earlier about the accessibility of authoring tools, and we have this, this conference day today, so there’s more, uh, more talk about it, and that is great. We see more people focus on it. But I think one of the main reasons is that WCAG is a standard that is embraced by so many governments worldwide, and the one thing that they, uh, put in, into legislation often. ATAG is, is not, but it can really help to, to meet that WCAG legislation.

So I hope to have showed that a bit in this talk, as well, that these things can really play together.

Ahmed: Awesome. Since we talked about the content management system being an accessibility assistant, the next few questions focuses on WordPress. So, this is my personal question to you: how ready do you think WordPress is, right now, to serve as an accessibility assistant among the CMSs that are out ther?

Hidde: Yeah, so I look at a lot of different CMSs for, for my work, and my work is vendor-neutral, so to say, so I don’t look too much at specifics. I do know in WordPress there are things like, um, good options for alternative text for, for images, so there’s, uh, clear information on what you should do there, I think that’s very helpful. Um, there is also something about color contrast, I remember?

That will, um, show you if you have the, the wrong color contrast, and help you get it right. Uh, I think those are, those are great features. Um, I think there’s a page structure thing, as well, so there’s, there’s a bunch of things in WordPress that really can help people get their accessibility right. But also work to do. I think, uh, people of the accessibility team, and organizer of this, this event, will be more up to date with, with the things that are still being worked on.

Ahmed: Yeah, we can certainly look towards the future. So, if you had to rate WordPress as an accessibility assistant, how would you rate it amongst a double A and triple A – I know it can get controversial, but up to you, if you want to make any comments.

Hidde: I, I cannot possibly comment on that, because we we look at all the different CMSs, and we want everyone to, to meet as many criteria as possible. Good thing to mention there is that, um, it’s not about meeting all of ATAG, or being completely compliant. Just like with WCAG, that is pretty hard to do, and not many organizations do it. Um, and they have to, by law, but you know it’s a continuous process.

And one person updates one image, it could be inaccessible. The point is really to meet as many of these criteria as possible, and, um, you know every, every little bit really, really helps. And we see that a lot, that organizations are, are doing that. And also that CMSs are making small improvements, and they are all helpful, and the end users will, will be happy with these huge improvements, I think.

Ahmed: Uh, I must admit, Hidde, that our talk is certainly sparking a little bit of conversation in the chat feed, we’re getting a few more questions as we speak. We have time, so the next question is on Craft CMS. Is Craft CMS much better than WordPress in terms of the accessibility of the editor, thoughts?

Hidde: Are you referring to the W3C choice of, uh, of CMS?

Ahmed: I suppose so, I suppose that’s the question.

Hidde: Uh, so I’d really like to refer to the the blog post I’ve already published about this, because, um, I had a tiny part in, in discussing this internally, of course. Um, the main, the main points are we, we found not many, um, not many tools meet all of our criteria that we need, and that’s a lot of different criteria. So we, we need an accessible CMS, we need a CMS that supports internationalization, because we work with the global community, um, bunch of different things, basically, that we’ve decided our CMS choice based on.

Accessibility was, was one of them, and in my work I really tried to convince other organizations to do what we did – make accessibility part of that choice, because, uh, it’s going to help you in the process, like I showed in the slides.

Um, they did that, so the, the vendor that we hired for the, the new website they, they looked at these different, um, aspects and also at accessibility, uh, and they looked at how they, how they feel it is going to improve. And that is, you know, that’s a different, difficult thing to, uh, to assess. Because, you know, you cannot look into the future. Um, but yeah, it seems like, like for them that the, the Craft CMS had, had more commitment, uh maybe also from the top, to, uh, to make their accessibility features better. Um, but yeah, maybe WordPress will be a better choice for other organizations. It’s really tricky to, uh, to say, and I can’t comment in too much detail about that.

Ahmed: That’s fair enough. Uh, then, I, I think I can understand where you’re coming from. So, uh, such forum, when, where we discuss and we try to assess, uh, CMSs, if they’re accessibility-ready, so such questions are quite realistic, I suppose. But then again, I request you to go through our website and answer the question. I’m sure you will be given the link later, also viewers, we’ve also shared the slides to the presentation by Hidde. Before, I can ask you the last question. So, the last one says: Have you tried to use ACF and a headless front-end as editor to get accessibility content creation?

Hidde: Yes. Not in my capacity at the W3C, but I do have from personal experience with that. Something in general you can say about, um, so, so ACF is an Advanced Custom Field, right, so you define your own fields. Um, and what’s interesting about that, is that you could have just strings of text that people put in, and then you can invent your own markup around that, so you control all of the accessibility. Uh, you could do it badly, and you could do it greatly, right. So, like I mentioned, some CMSs don’t have the option to add captions to a video.

Um, if you create your own fields, then you can create a field for captions, so you can really control that, uh yourself, and then make it more of an accessibility assistant in a way, as well, because you could explain why they need captions, do it in a way that is the perfect tone of voice, and that will inspire people to do it, rather than, uh, make them annoyed.

Because I saw someone asked like, you know, how can we, uh, avoid that people choose a different CMS if we confront them with accessibility too much. Uh, so yeah we have that positive tone of voice. So that’s something you can really control, if you define your own fields. Uh, so yeah, that’s uh, if you are, uh, an integrator with, with WordPress, and I think that makes a lot of sense to, to try and find your own fields, and get full control over, over what these fields look like and what they say.

Ahmed: Thank you so much, Hidde, with your time, your effort, and patience with the questions. Um, before we can wrap up, I would like to ask you one personal question: How would you like the stakeholders out there, who can make a difference to initiatives such as WordPress Accessibility Day, we know this is only happening for the first time, uh, what if you had a, um, had a platform, if you had a voice, what would your message be out there for the people who can make the difference?

Hidde: Uh, the difference in choosing, making,

Ahmed: making such initiatives better and more accessible. Hidde: Uh, like the today’s event or…

Ahmed: Today’s event, yes. Yes, thank you.

Hidde: That’s a tricky one. I, I don’t know. I mean there’s, uh, there’s captions, um, so that’s, that’s good. Uh, I don’t know. I haven’t looked too much in, into the accessibility aspects of today’s event.

Ahmed: I’m sure we will have your support for the future, so on that note, we come to the end of this session, um, your CMS is an Accessibility Assistant. I want to personally thank Hidde for being patient enough, and answering all the questions, um, also I want to give a huge shout out to Harish, who has been acting as the moderator for this session, posting the questions on our site.

Also, I would like to give a huge shout out to the session manager, Stefano. working in the background. So I also would like to thank everyone for attending with Hidde and myself. You can continue the conversation using hashtag WPAD, hashtag WPAD2020 add the at of @wpaccessibility. Don’t forget to attend the next talk: If it’s true, it ain’t bragging: choosing a CMS for accessibility”, with Mitchell Evan and myself, right at 9:00 am UTC, here in the same time. Until that happens, see you right here after the break. Thank you so much, Hidde. Bye bye!

Hidde: Thanks so much for having me!