>>ROBOTIC VOICE: Welcome to Technica11y!
>>MICHAEL BECK: Hi ladies and gentlemen and all variations there upon, welcome to this -- what month is it? It's July [Laughs] -- July 2021 webisode of technica11y! Thank you for joining us.
Today we have Hidde DeVries, who is a Web Accessibility Specialist and a Web Developer at the W3C and the Web Accessibility Initiative. He worked on accessibility authoring tools. Hello Hidde, welcome.
>>HIDDE DEVRIES: Hi, hello!
>>MICHAEL BECK: Great to have you with us today! Hidde will be talking about how your CMS is your accessibility assistant. Whenever content designer creates content, the CMS could help with the accessibility of it. For instance, the obvious one, the designer drops in an image, this CMS could point to the text alternative or calculate the consequences of color contrast but I'll let Hidde talk more about that.
As usual, we'll be doing moderated questions afterwards. And if once that's completed, if anyone has any more questions, anything accessibility related, we can go ahead and throw that out to the consortium we have here. And so without further ado, it's all yours Hidde.
>>HIDDE DEVRIES: Thanks, Michael. Thanks so much. Yeah, so as Michael said, I will be talking about how CMS's can be an accessibility assistance. So I'm Hidde, I am presenting from Rotterdam in the Netherlands. And I work as an Accessibility Specialist at the W3C, which means that I spend most of my time on, on accessibility. This doesn't make me an expert, per se, but I do spend time on it. And I worked on the Web Accessibility Initiative, which is a part of the W3C that promotes web accessibility in many different ways. I should say we have a website where we write about all sorts of things related to accessibility. You can read more about planning, designing, developing, testing, advocating and training accessibility. So there's a lot of variety there, which me my colleagues work on lots of interesting stuff to find. So yeah, I did want to want to mention that's w3.org/WAI. So that's a way.
But today, we are here to talk about authoring tools. And for those who are not familiar with the word, authoring tools, means tools that create web content. So they are tools that you can use to generate anything that goes on to the web that will get its own URL, or that will be kind of presented in a browser or in something browser like. And authoring tools, because they are the tools that create web content, if we're interested in accessible web content, we should know that the authoring tools are also tools that can improve a lot of accessibility at once because they are the thing that you create the content in. So there's lots of opportunity there to improve accessibility.
Now, it would be good I think, to give you some examples of what authoring tools are. Obviously, CMS's are our authoring tools but also WYSIWYG editors that you can use to create content while seeing what you're doing. So it's What You See Is What You Get (WYSIWYG) editors. Authoring tools also include, course creators or learning management systems. So if you work in higher education, in a university, there's lots of authoring going on there. Like you might be presenting some exam to your students, you may be giving them access to the latest marks or something like that. That will happens through web interfaces. That is web content and it is created in early management systems. Of course, I mentioned CMS's Wikis are another example. Save as HTML interfaces that you can have in things like Word. Social media, if you're creating a tweet, you are creating web content. Form generators are a big one. Lots of accessibility problems exist in forms. So there's a lot to win if the creator helps you do that properly.
And then site builders are another category and they are increasingly popular, especially site builders that help you create web pages without writing any code. They call those, "no code," as well, which, you know, is a bit of a misnomer because obviously there's code behind it and as an accessibility person, I'm interested in ensuring that that code that is there is good and is accessible and takes accessibility into account.
Now, specifically for CMS's there's a lot you can think about. There's the CMS itself, of course, but it's also, this whole ecosystem that's usually around CMS's, like plugins for them. Think about things like form builders, field managers, cookie, banner thingies, stuff, where you manage events, social buttons, web shops, all of that. There are plugins for that for most CMS's and those plugins also have an accessibility angle. And of course, then there's themes too. If the CMS provides a number of themes or if it provides capabilities, where third parties can create their own themes. Again, if you're downloading a theme, you should be downloading the accessible theme. So all of this has accessibility angles.
>>HIDDE DEVRIES: Why don't we want that? Well, of course, the web is for everyone. That's the promise of the web. This is for everyone. And that is definitely something that way, that we believe and that we try to address to a number of different web standards.
The first one I want to talk about is WCAG. It's the one that you're probably familiar with if you're in the accessibility field. So WCAG stands for Web Content Accessibility Guidelines and it is the set of guidelines, it's a standard that many governments use when they mandate any kind of accessibility thing. So many governments around the world will say, "Here's WCAG, and that's how you should be doing accessibility." So WCAG is, is a great way to measure accessibility and to look at how accessible a given website is. It helps governments prepare, or compare as well, between different websites as well. So if there's 10 departments that all have a website, and therefore generate the report based on WCAG, then you can use that report and compare somewhat, what the level of accessibility is. It's not perfect, it's not gonna cover everything, it is a minimum that you can use. But you know, generally it is what people use to measure web content.
But besides web content, there's a whole lot more that we can measure. And if we want an accessible web, it is also important that the tools we use to look at our content are also accessible. That's where browsers come in, browsers also need to be accessible. If someone with disabilities wants to use their computer to go to a website, then the tool that they use, the browser, will also need to be accessible, and UAAG is a standard that addresses that. So it stands for User Agent Accessibility Guidelines. And a lot of it is implemented in many browsers, some of it is not. And UAAG is specifically for that. So making sure that the software that displays web content is accessible, just like the content itself.
And then there's ATAG, which is about authoring tools. It's the Authoring Tools Accessibility Guidelines. Again, we like that abbreviation AG for guidelines, and the Authoring Tools Accessibility Guidelines are what we'll be talking about today. They are about those tools that create web content, and they're essential. They're essential for realizing that vision of that, you know, the web is for everyone. Authoring tools are essential besides the content and browsers because with accessible authoring tools and with tools that really embed accessibility, we're able to include more content creators, so more people will be able to create content for the web. That's important. We want to hear all voices on the web. And also, content creators can get some help with the right authoring tools to fix accessibility problems before their website goes live. That's really interesting. We'll be talking about that a bit more later on. But the gist of it is that all authoring tools sit in kind of the early stages of the development of web sites before you ship the website you've created, you author it. So if we're able to fix accessibility problems during authoring, that's nice and early. We can do that before the website goes live rather than after it's gone live. That's a good opportunity. Yeah, we'll be talking about that in more detail soon.
So the latest generation of the ATAG Center is ATAG 2.0. It's a couple of years old. But it's the latest we've got. There's a document online called, "ATAG at a Glance." By the way, links for this presentation will be available later on. I'm sure the Technica11y folks will be able to share that later on. But I have this web page where I collect all my presentations and links will be available there for you to find. So there's this page called "ATAG at a Glance," that will give you an overview of ATAG or you can stay for this presentation and I'll be giving you a bit of an overview as well.
So there's two parts to ATAG, which address two different parts of the web. One is the editing experience. So that's Part A of ATAG, and it's all about whether people with disabilities are able to edit the website to create web content. So it is about ensuring that the CMS itself or the learning management system, or any of these systems are accessible for people with disabilities. Then the second file for B is about the output of those systems. It is about the end user. So where part A is about the user of the CMS, Part B is about the end user that's going to use whatever the CMS produces. And you can think of that as the HTML that is being outputted and trying to make sure that HTML is, is accessible.
>>HIDDE DEVRIES: So let's talk a bit about Part A of ATAG, the accessibility of the editing experience. This may affect people like Antonio who is 52, and a doctor and colorblind. He wants to set up a recurring prescription for one of his patients, and he may be using this medical system that, in fact creates a web page that this patient is going to see. But you know, it is an authoring tool in that sense. And he wants to make sure that, we want to make sure that he can be setting up that prescription, even though it's been applied.
Ellis who is 27, and an HR Specialist has broken her arm. It's technically not a disability, but it is a temporary impairment to her at least. She wants to publish a story about one of her colleagues promotions on the company intranet.
Or Mei, who is a teacher, 32, reduce dexterity, she wants to upload a take home exam for students.
Or Anne, who is 21, an influencer and motor impaired, wants to publish her latest vlog on social media.
So all of these people have in common that they want to publish stuff on the web, on a web platform on some internal system, sometimes on an external system somewhere on the web, and they want to create that web content. They want to make sure that it works with their environment. We want to make sure it does.
So a couple of things that ATAG recommends that I'll be kind of paraphrasing ATAG, these are not literal quotes from ATAG but these are things that, in the spirit of ATAG, authoring tools can do to make sure they work for people with disabilities.
One is that they test with text zoom. That's something you might know from WCAG, if you're testing WCAG, you will be doing this with regular web pages. But it's just as important in admin interfaces of CMS's because when you zoom, you want to make sure that none of the text overlaps, so that the content is readable, that's visible on the page.
You want to make sure that there are alternatives for all of the icons. There are some CMS's that have menu bars that are mostly consisting of icons. And we want to make sure that those icons have tax authorities so that people with disabilities are able to use them. We also want to make sure that they work with keyboards. It's quite a common issue amongst CMS's that that I looked at for this project, that icons in the menu or generally buttons and controls throughout the interface are not available for the keyboard. So you're using your keyboard to look and see maybe I want to go to my admin panel, and you're not able to get there with the keyboard. So making it work with keyboard has two parts to it, you want to make sure there's visible focus so that you can see where you are and also that you can use the controls. So that you can press buttons, activate them, open menus and those sorts of things.
So menu authoring tools don't allow for doing that. So before you purchase an authoring tool or decide to use one, make sure that it does work with keyboard. Also make sure that previews are displayed excessively. Because many CMS's will give you a preview of the content you've just created. For instance, on GitHub you can write the markdown file and then you can press preview changes, it's going to give you a preview of that content. You want to make sure that preview is accessible as well. There are some authoring tools that, that fail at this and have previews that are not available or kind of inaccessible in some way to the end user and that's not great.
And the last thing that authoring tools could do to make sure they're accessible to people with disabilities, is to help with spelling, so that people with disabilities like dyslexia are able to write content that doesn't contain spelling mistakes so they can get some help with that and help with spelling exists in the first place and also that the spelling help is available to use with visibility. So if there is a way to mark words that are spelled wrong, like in this screenshot, it says "auttoring," it's spelled wrong and there's a red line just underneath that, that indication of you know, this word is wrong, that that's also available to users with disabilities in some way.
>>HIDDE DEVRIES: Then Part B of ATAG is about the CMS ensuring that the content that's being produced is also accessible. So the CMS helping to produce accessible content. And there's a lot to accessible content, right? We want to make sure that tables have headers, that form fields have labels, that hero images have enough contrast with the text that is positioned on top of them. That videos are captioned, that content with multiple languages has lang attributes, that words or tags are nested according to specification, that carousels can pause and that there are sensible heading structures.
So lots of different things that are all things that we mean when we talk about accessible content. All of these things are, are important. And all of these things are stuff that a CMS could potentially help with, give suggestion about, maybe try and help avoid these problems. So if you want to avoid that, you want to avoid tables that don't have headers, you want to avoid nameless form fields, illegible text, no captions on videos, multilingual content that don't have lang attributes, non standard nesting carousels that don't have false buttons and also heading for the wrong reasons.
There are CMS's that address some of these problems, right? They will warn you, if you've created a field that doesn't have a name. There are authoring tools that will say well, "wait a minute, this is not nested properly." So that can be done. And some of these can be recognized automatically, and an authoring tool could, in other words, help the content editor avoid this inaccessibility.
Good CMS's can help content editors to make their content more accessible. And that is relevant to a lot of people like Alita who's 26, a privacy lawyer. She's blind and she wants to arrange this lunch for one of her clients to take them out for lunch and wants to find out if the restaurant serves vegan food. Or Rick, who is an investor with severe hearing loss, wants to watch this interview with the Prime Minister on TV because maybe they've just announced some new rules around COVID or released some of them, as is the case in some parts of the world now. Xiao, who is 15, a student with low vision, wants to just access the results for their mathematics test. Or Erica is 31 nd a photographer with RSI wants to file a tax return online. So these are all kinds of things that these people want to be doing. All of these personas want to do things that are part of their life and they don't want to have barriers when they when they try to do those things.
So far, the beauty of ATAG is really about kind of trying to avoid these barriers for these people. Wanting to ensure that this stuff just works. So one thing that a CMS could do is generate accessible content. So when there's a table generator, that it generates accessible tables with the right headers, that avoids empty links. So when you're creating a link, and don't put any content in it, or put an image in it without alternative text, that the system warns and says, "Wait a minute, you need to provide a name." In fact, when content is generated, you could prompt for required accessibility information. So if someone inserts a table, you could say, "Well, wait a minute, what's this table called?" Or when there's an image, it could say, "You need to put alternative text there," or indicate that it doesn't need alternative text. Or when there's a form field that it asks you for a label.
You could also, CMS could also ask for, do some automated accessibility checks for you. So that you can avoid problems there. Only a small part of accessibility problems can be found automatically. But as someone who does audits sometimes, I know that a lot of problems that auditors find are actually things that could be found by automated tools. So these are all things we could avoid in the authoring process.
When content is generated, you could also do some manual checks. And the CMS could help you do that. It could say, you know, "Before you want to save this page, are you sure this heading structure is okay?" Some CMS's will display a list of headings, right next to a field of content so that you can glance over that and make sure it's good. Or if it allows you to manage image alternatives and some kind of media library, you could also do a quick check and say, "Does an alternative apply in this use case?" Does it make sense in this page, because sometimes it doesn't.
>>HIDDE DEVRIES: A CMS also allows for creating accessible content. So some CMS's don't allow you to add alternative text or images or captions to videos. Social media used to be known for that. And in some social media, it's still quite hard to add alternative text to images. So you know, to think an ATAG that is a, you know, the authoring tool should allow in the first place to create that accessible content. There should be fields for our text.
And that's also important when you're customizing a CMS and you're creating some custom fields that do something very specific. If that includes an image that should also include the alternative text field for that image. And that's something that people commonly forget when they build their own kind of components. If you allow for images, you should also allow for alternative text. If you allow templates, or there's some kind of gallery for accessible templates, then it's helpful if those templates are accessible, or if there's a way to find the templates that are accessible or have accessibility built in. For us, fine that is possible. If you provide UI components, like some way to add a carousel, if you really must, or tabs for that matter, ensure that they are accessible, that makes a big difference. If a CMS comes with a tabs component, it is probably not going to be used in one place. If your CMS has more than one customer, you are going to make more than one website accessible with that effort. So that is extremely helpful. In the specification, this is called pre-authored content. I like to call it UI components. But basically anything that you can repeat, like tabs or like a carousel is something where you can make a big difference. If you ensure that it is accessible. If you decide to test it with users with disabilities, that can make a big difference because that is going to be repeated over and over. And that way, you can ensure that you're repeating accessibility rather than repeating inaccessibility. So that's helpful.
Something else that the CMS could do quite well is warn users when they introduce a color contrast issue. So for instance, I have this image of a black cat with some white text on top of it. And it has plenty of contrast, because the photo is quite dark the cat is quite dark, and the text is quite light. So I have good contrast there. But if the CMS allows me to replace this image, and someone replaces it with a perfectly fine photo of Korean food, that happens to be quite light, then it could warn and say, you know, "At this point, when you've just replaced this image, you no longer have enough contrast. So maybe you should try a background color on the text or a larger text or bolder font." Automated tools could figure out what to do here and make suggestions to the end user. Or even have a button where as an end user, you can say, "Yes, please do add a backplate to this text, please add a black background to this text or something like that."
Spell checkers are also helpful on on the B side of ATAG. If you add a spell checker to content fields, you can avoid things to go unnoticed like when I have a submit button that has a W instead of a U, maybe when I look at it visually, I didn't notice that because a W looks so much like a U, but someone with voice control technology or maybe you're screenreader might make them super confused if that's the name of the button. So you want to make sure that you know you remove spelling mistakes from your content.
Readability is another huge thing in accessibility, you want to make sure that content is readable. Plugins could provide readability levels so whenever you add any content, that it is checked for readability, so that publishing hard to read content, is a little bit harder.
>>HIDDE DEVRIES: Something else that ATAG recommends is to have accessible examples. Such as, you know, when you have templates or documentation that you double check that all of the code examples there, have accessibility practices embedded into them.
So basically, summarizing all of that, the right CMS can encourage more accessible content and in that sense, be a personal accessibility assistant. That's the vision I have for CMS's. I think that can make CMS's a lot better. If you own a CMS company, I encourage you to put it as your unique selling point, because there are a lot of websites out there who want to be accessible, legally have to be accessible, or willed to be accessible for, you know, a number of reasons. And if you can offer them a CMS that helps them achieve that accessibility, you can sell your CMS to these people, because it's hard to find CMS's that have all of the features I just mentioned. Many of them are in some CMS's, but if you are the CMS that has most of them, you have a unique selling point there.
Now, let's look a bit at when better authoring tools can help in terms of when you have an organization and you're trying to build stuff for the web, you may have a process like this, which is a bit linear, waterfally. You start with planning new interaction design, visual design, development, quality assurance, and then you launch a product. Maybe your process looks different than it has many of those tasks kind of put together and has like a multidisciplinary team, it doesn't really matter. Usually you will be going back and forth between different phases like maybe from launch, you will go back to planning or to interaction design, or visual design to kind of sometimes change part of your stuff that you're working on. Sometimes you might be going back from quality assurance to visual design. So you may be making a lot of movements between these different phases. So it is important to know what you can do about accessible authoring in each of those phases. For instance, if you are in the planning or strategy phase, what you can do is choose an authoring tool that supports your accessibility. Choose an authoring tool that does many of the things that I've mentioned today. And if you do that, it will become easier to get your accessibility right. If you do interaction design, you could document how to author excessively like, if you have a form generator, you can document which buttons to press to make sure there's a level that sort of thing. You can test your authoring with users with disabilities to make sure that all of that works well. If you do visual design, you can set constraints for customized color combinations for stuff like contrast, or you can provide accessible examples like large enough touch targets or those sorts of things.
If you're in development, you can pick the themes that have accessibility support or plugins that do. If you're selecting components, again you can look for that accessibility label. Make sure to test it thoroughly because there are more claims for accessibility and actual accessible problem products.
In quality assurance, you can work on things like embedding automated accessibility tests in the authoring process. So when someone writes new content that is actually automatically tagged as well. Basically, you can do things all the way until launch.
Now beyond ATAG, ATAG is a bunch of years old. There's a lot of things that we can do in the spirit of ATAG that can help a lot with with web accessibility. Things that I know of is this component for react that will allow you to, and I think it's actually done by Tenon folks behind this, this meetup. It's a react component that will let you do headings automatically. So you have a heading component that's generic, and then it will automatically set the right heading level for you, based on where you are at the structure, so that you can't make mistakes, what your headings. Something else that you can do is run automated tests. As I mentioned before, they don't cover everything, they only cover a small minority. Some say 20%. Some say 40. depends who the person is that's telling you. But generally, automated tests will cover some part of your accessibility. And that's helpful to get those things out of the way. You could also use accessibility style sheets that are stylesheets that will mark things in your content that are wrong, like missing alt text and that sort of thing.
If you have those style sheets, in the preview in your authoring environment, you can also warn users, like, "Oh, wait, here's an image that doesn't have an alt text," or that sort of thing. Now, as I mentioned, at WAI, we think authoring tools are one of the secrets to making that more accessible to realizing that vision of this is for everyone. Just along with web content and browsers. We also need to make sure that authoring tools are in a good state. And one of the things we've done for that is obviously add ATAG standard and a document called, "Implementing any ATAG 2.0." This document contains a lot of things that I have talked about today. And some practical examples. It's a little bit like techniques and understanding that you may be familiar with for WCAG. But also more recently, because this document is from 2015. It's many years old. More recently, we worked on a project called, "WAI Guide," which is what I'm involved with. It's co funded by the European Commission, who wants to make sure that the web works for everyone. And one of the things we do there is called, "Accelerate Support for Accessible Authoring." And as part of that work, I'm giving this presentation. But I'm also working on a list of authoring tools that will allow you to filter by ATAG criteria.
So you could look for a CMS that meets certain parts of ATAG. You can find tools, basically, that support accessibility. So when you are in that procurement phase, you can actually say, I'm going to purchase a tool that's going to help me with my accessibility better. And folks will be able to submit their own tool as well. So if you work on something that is an authoring tool, I've given a number of examples at the start. There are more authoring tools than people know and more things are authoring tools than people realize. So anything that creates web content, whether it's a CMS or plugin or theme or whatever, you can submit your tool for this list. And we plan to ship that sometime this year. To really enable people who want to make decisions, purchasing decisions, to really look at whether the tools that they want to purchase have accessibility support.
Now, one thing we realized when we were building this list is that we weren't too sure which things to include, because, obviously, we want this to be something that is objective. And the most objective thing we have is the ATAG standard. So what we've created two is an ATAG report tool, that will allow you to go through the ATAG standard, report on the criteria that are in there, and then save that as a JSON file, HTML file, and then put it on your website. So if you sell CMS's or plugins, you can publish an ATAG report on your website. And this would also be able to be in kind of the input mechanism for that list of all variables that we're working on. So if you have a tool, you can use the ATAG report tool that's currently live. Again, I'll be sharing links later as well. That stuff will allow you to... Yeah, the tool will allow you to create a report. And then we can display your tool into our list, as well. So we welcome submissions for that.
So concluding, the main things I would love you to take away from this is that CMS's and other authoring tools are essential for an accessible web. If we want the web to be accessible, we've got to address authoring tools. And CMS'S are great at being an accessibility assistant. They can help content editors get accessibility rights. So yeah, please do spread that message. If your client is thinking about purchasing a new CMS, or if you are selling CMS's or other tools that create web content then think about how well it meets the ATAG standard. Yeah, try to meet it as much as possible so that people with disabilities can create web content, or can access content that is created by by these authoring tools. So that's all for, for me. I'd like to welcome questions. Now if you have any.
>>MICHAEL BECK: Yes, thank you so much Hidde. It's actually Mike Gifford made a comment earlier that kind of hit one of the things you were talking about just at the end there. He noted that Drupal has certainly tried to promote ATAG but very few people are thinking about how the authoring tool can make a difference that people are just aren't asking for it yet. So it really is kind of up to us to evangelize ATAG in CMS as an accessibility assistant with with people. So I think it's a good point.
>>HIDDE DEVRIES: Yeah, totally agree with what Mike says there. It is not something that people are asking for just yet. But we can change that right especially as accessibility evangelists. We can tell our clients about this with the ATAG report tool and this list of authoring tools, we are also trying to make a small dent in that and we are hoping to get tools including Drupal all through this list and yeah, ensure that people are going to use this to find their tools that support accessibility and hopefully it will also encouraged vendors that create tools to really want to be on that list. And yeah, so we hope to create that effect their with those things.
>>MICHAEL BECK: Yeah, I certainly am thankful for the CMS we use for the Technica11y website that has all those kind of prompts for things, (it) doesn't let me go forward if I forget to add an alt text or something. Because it's just the name of the game, people do that sometimes. You sometimes forget or you're in a hurry, go past it. But CMS will tell you "Stop! You need to do this first. Slow down."
>>HIDDE DEVRIES: And I'll say as an accessibility person, I forget it. So yeah, obviously people who don't have that experience, they will forget it. Exactly. And that's fine. If we can point them at it we're making it a bit easier for them to not forget or correct that. Yeah.
>>MICHAEL BECK: All right. Does anyone else have any questions? PJ Gardner asked, Are there places to report problems with existing authoring tools that we find as we work?
>>HIDDE DEVRIES: I can give you my email address (laughs). I'm definitely interested to hear about this. I know that individual governments have places where you could report accessibility problems in general. So it may be helpful to report there. I don't know about other governments. I know the Dutch government has nice so you can report things that your encounter here and I think across Europe, government generally have that. And there maybe place in other parts too. But if there's a place to report problems with websites, do also report problems in authoring tools there. Because it is important that everyone knows that in authoring tools, it matters as much as everyone else.
>>MICHAEL BECK: Rian asks, "When you create a plugin to an inaccessible CMS, but do a lot to help people create accessible content with your plugin. How do you address this as an ATAG for your plugin?" - because you're depending on inaccessible CMS.
>>HIDDE DEVRIES: Yeah, there's this notion of partial reports where people say, "Well, this part of the website we've looked at, this other part we've not." I think you could do the same as in WCAG reports, right? There is, I think you could apply the same principle to ATAG reports and say, "This report is just about this," let's say a form generator or something like that. It is not about the CMS itself. And I think that's commonly the case in, in authoring tools that they rely on, on components that are sometimes more accessible than the tool itself, sometimes less accessible. So we'll have to do a partial reporting on that.
>>MICHAEL BECK: Most important thing is just letting people, letting them know. Just whatever way you can let them know. Mike has another comment or question, "Commonly used tools like CKEditor have had a huge impact for authors, how do we increase the demand for a tag and essential tools?"
>>HIDDE DEVRIES: Yeah, we're hoping that may somehow follow from having a list and kind of making people more aware of these these demands. I mean, if Drupal is going to work on the accessibility of the CMS and editors that's built in to Drupal isn't accessible, then Drupal folks will likely reach out to the editor folks. I don't know if that CKEditor might probably know this, or another one. But yeah, that's that's hopefully what will follow if we ask CMS's to be accessible that they also ask the tools that are used within those CMS's like CKEditor. So yeah, please continue to put pressure. [Laughs]
>>MICHAEL BECK: Mike said, "It is CKEditor, and we've been trying to put pressure on them." So yeah, keep it up. That's basically all we can do is keep it up.
Anyone else? Have a question for Hidde? Or at this point, any accessibility question that's bothering you. If you're stuck on something, we have a nice little group here of people that will... we have a really nice group of people with lots of knowledge here today.
While you're thinking... Well there your go: "Plain language isn't presently part of a tag. Nor is it part ofWCAG 2.1 or 2.2. Any idea when we'll see an update? Maybe ATAG 2.1?"
>>HIDDE DEVRIES: Yeah, they're currently no plans for ATAG 2.1. There are plans for embedding some of this stuff in ATAG into the next version of WCAG, (Michael Beck squeals giddily in the background) also known as a "Silver." So there is some thought about not only making WCAG about web content, but also about browsers and authoring tools, to kind of embed the authoring tool stuff inside of WCAG. But WCAG 3.0 is far future. It's just being worked on. But there is some talk about that. ATAG 2.1 is less likely. And for those who don't know, there is some mappings between ATAG 2.0. And WCAG 2.0. So sometimes ATAG will say, "Please meet this part of a WCAG, and it will say meet that part of WCAG 2.0." So there's a mapping between ATAG 2.0 WCAG 2.0, not to 2.1. So that that doesn't exist, and I don't think it's likely it will exist in the future. Because efforts are focused more on WCAG 3 at the moment.
>>MICHAEL BECK: I think there might be actually, that's a really good idea, because WCAG is the, the hot button term people know, if it's already, ATAG stuff is already built in the WCAG, in some way, shape, or form. There'll be at least aware of it and maybe look into it a little further, me.
Jules notes that she was surprised that EN301549 points to ATAG. And they just advise the client to use that for choosing their vendor. So, oh, that's nice to know. I didn't know that either [Chuckles].
But that specification, that conformance criteria pointed to ATAG, cool.
Mike City is going to go make sure that goes into the Wikipedia page to highlight it a bit more, which is good.
That's good. All right. No one has any more questions. Next month, we're going to have someone who's in our audience today, I believe. Yep, there she is Sarah Brodwall. She will be discussing disclosure widgets, modal windows and toast notifications, those kinds of patterns that we have for showing the user more information after the page loads. She'll talk about how to choose the best pattern for the purpose and context and how to ensure that the design and implementation provide a positive user experience. Is that correct? No, I'm sorry, Sarah, you're not on until September [Laughs].
I'm, I'm a peeping you're talk two months early!
Next month, we'll actually have Jesse Hausler. That will be talking about drag and drop. That, that pesky little drag and drop and the best ways to implement it, those in an accessible way. So again, sorry about that, Sarah, you'll get a you have a neat, neat little glimpse into the future, knowing that Sara will be presenting on September 1st. But the next one is on August 4th - Jessie Hausler talking about drag and drop. So thank you all again for showing up. Thank you Hidde, for that wonderful presentation. And we will see you all next month.