 So welcome to the last presentation of the day and of the conference. Now after that we'll just have a closing note and a party. Everyone's ready for the party. And tomorrow I hope you all come into the code sprint to tackle a couple of issues, those pesky issues in those modules. Welcome to my presentation, Accessibility in the WizardWig Editors. So we have accessibility as always sort of the last thing on the list. It's a last presentation of the day as well, but it's very important. Hello, my name is Jana. I'm a software engineer from Tomato Elephant Studio. Here's my Drupal.org profile. I've been presenting here and there on the Meetups and on Drupal South when I build my presentation I try to find out something new and maybe solve a couple of problems along the way. Who is this presentation for? So it's presentation for everyone, for project managers, project owners, designers, developers and testers. And on the agenda we've got what is web accessibility? What's accessibility for WizardWig Editors? The CK Editor 5 and accessibility as CK Editor 5 is now default editor for Drupal 10. Drupal 10, CK Editor and accessibility. And we'll go through accessibility by design checklist. So what is accessibility on the web development? So it's just enabling users all from different walks of life and abilities to be able to use our products, our services. Why is it important? You need to give everyone equal access to your services and to your products. It creates a better user experience. It creates a better discoverability of your content for search engine optimization. And also it's a legislative requirement. So in Australia and New Zealand, for example in New Zealand the guidelines go every web page must meet CAC 2.1 at level 2 AA subject to a few exceptions and must they defined as indicates an absolute requirement. So they're pretty strict in New Zealand. So there are a couple of standards were developed during over the years from the web accessibility initiative from web consortium. And mostly the minimum level, especially if you're working in the government environment, it's guidelines 2.1 at AA level. There's lots of resources of what exactly that includes. And the accessibility laws are enforced sometimes in the United States more than in Australia and New Zealand. I haven't found any litigations in New Zealand, but in Australia there were a couple of interesting cases. One especially for the Sydney organizing committee for the Olympic Games. And the case was the beautiful website just had a lot of images that didn't have alternative text. So users couldn't use the website. And the other one was very interesting as well. So the person Manaj versus calls. So the lady had the issue, so she was blind. And she was using the website and actually contacting calls saying, hey, you need to improve your services. And they since like 2008. And they did improve in 2010. They released a new website. She was quite happy that could use the website. And in 2013 they released a new version of the website that was unusable for the users with special needs. So she was like, well, now you... So they went from litigation and it was settled privately. And calls obviously improved their website. So yes, just don't go back on accessibility. So in this presentation we'll focus on accessibility of WYSIWYG editors and how the guidelines actually applied to the editor itself. The editor is a form with a bunch of buttons of how you can format your text. In short, it's a work in progress. Some WYSIWYG editors are better. Some are worse. But first let's look at what actually which guidelines we can apply to the WYSIWYG editors. So it's use of color, alternative text alternatives. It's making sure that if something is available by hover, it's also available if you focus on it with keyboard. It's operable so you can use keyboard to create your content that you don't need to use the mouse alone. It's understandable. So if you go to your WYSIWYG editor on this particular page of this content type, the buttons on your WYSIWYG editor are in the same order as if you would edit on a different content type. Because in Drupal you can configure pretty much everything with the CK Editor layouts and features. And it has to be compatible. So if the button just has an icon on it, there should be a label on it. And if you're building your own WYSIWYG editor or if you're taking one off the shelf, making sure that it complies with name, role, value, accessibility standards. So let's look at some different WYSIWYG editors. So I've picked five. Most are on GitHub. They're actively maintained. They are not marked down only. So some are very popular, but they're marked down only editors. I'm looking at the accessibility statement of those editors. I'm looking at the issue queue, especially for accessibility issues, and doing a quick test, an automated test or a manual test. So the automated test, I usually use Wave plugin. There's many, many different plugins that you can use. That's one of them that you just activate and it runs through the website and shows you where the potential issues might be. It doesn't catch everything. It just catches something that automated tool can catch. And I also do the manual test with voiceover. If you have for macOS, it's built-in screen reader. There are other screen readers on different operating systems. It's quite easy to enable from settings accessibility, turn it on, and your computer will speak to you. So what are the most popular rich text editors? So we've got a couple. So this one is from WAPalizer. So Monaco and Ace, they are code editors. They are not rich text editors, but for code. So they don't render HTML. But all the other ones are quite popular. So I just added a tip tap as a replacement for one of them. So these ones are Quill, TipTap, ProElla, TinyMC, and CK Editor 5. I don't know if you've heard of any of those editors. So let's go with Quill. Have you ever heard about Quill? So Quill is actually quite popular. You probably use it every day. It's the Slack text editor with the Wiggins flag and also on LinkedIn. Here's a quick screenshot from the website, which is how a rich text editor looks like. It just looks like a text editor. And going through, it's very popular on GitHub. It has quite a few million downloads. The accessibility issue queue is very shallow. Out of so many issues, they don't really look into many issues. Also, there is no accessibility statement on their particular website or in documentation. There is no keyboard shortcuts into the toolbar. So that's quite questionable implementation. And when I ran the Wave plugin on the website, it looks very sad. In terms of the buttons don't have labels, so when you navigate it with the voice over, it just says button. So it doesn't actually save what button does. And also it doesn't have enough contrast on the by default implementation. Although when I ran the tool on Slack or LinkedIn, it's actually accessible because they obviously either fix that or they Slack or LinkedIn, they use their own implementation of the buttons. So next one is TipTap. Anyone heard of TipTap? So anyone's using Substack? Now a popular blogger writer platform, so that's used on the Substack. So there are a couple of implementations where one can be dynamic where you start typing and the toolbar shows up while you type. So it's also quite popular, heavily downloaded. Also with the accessibility issue queue, it's very shallow. You're not really looking into it. And they do have documentation for accessibility on their website, which says we don't really have any accessibility focus at this moment. Like, oh, okay. And when I did the ran Wave plugin on Substack, yeah, it's just even they didn't fully implement the accessibility of particular items, so it just doesn't have button labels, which is quite sad because it's a huge writer's platform. And also on a voiceover test, you don't see the buttons' labels. So the next one is Froella. Anyone heard of Froella? So this one is used in Salesforce. So yeah, it looks just like any other editor. And it's quite popular, not as popular as the other ones, because it's also a paid editor. It's not just open, it's open source, but you have to get a license for it. Accessibility issue queue is very shallow as well. But they do have a good documentation. And I guess maybe they have, and even they ran through the compliance statement for American market with their 508 compliance. So that's their accessibility statement that you can navigate with keyboard. You can do the shortcuts. And it's compliant to level 2.0. Well, but it's don't take their specific statement. Take it with a grain of salt basically. So you can see in this particular example, there's failing on, it's a level of the guidelines. So when you type in something and you selected the text, and the text looks underlined and italic, the buttons actually just, the only way they indicate that those tools are selected is with the color. And if you use the black and white, or if the person doesn't recognize the color changes, then it doesn't say anything. So it should have at least a border around the button. So that would be a fail. It's a very minor issue, but it's not 100% compliant as they say. And the big one, the TinyMCE, it's used by WordPress, Shopify, at Lysian. So it's a very, very big and popular one. That's a quick screenshot of how it looks like. It's very flexible, very big, quite popular with quite a few accessibility issues, and they're being moved and worked on. Because they are so, I guess, big and they have such high-profile clients, they do have accessibility documentation, extra plugins for usability and accessibility, extra settings, guidelines and keyboard shortcuts. But yes, this one is also not a free, rich text editor. And we'll get to the CK Editor 5 now. So CK Editor 5, besides being used for Drupal, is also used in Salesforce and Wix. So Wix is a little, it's a website building platform. Here's a quick screenshot of the editor. And the new version was released in 2018, already quite a few years ago. It's quite popular, it has quite a few accessibility issues in the queue, and they're being processed as well. There's a good documentation for keyboard shortcuts, but it's actually missing documentation for accessibility support and compliance, but it has a bot. So in CK Editor 4, they did have a really good accessibility guidelines, 2.1AA standard, and they addressed every single item on the list and the techniques they used. So it was really, really comprehensive. So in CK Editor 5, when I was looking through the queue, there was already someone saying, hey, where's the documentation? And I just plus one it and someone from the team replied, yeah, it's coming, just wait a minute, we'll fix in it. So in a couple of months, maybe they'll release a full-on accessibility compliance report. And they have a pretty good track record of accessibility releases with accessibility issues being fixed and released and documented. So that's not the full list for May 22 release. That's August 22, there is even more accessibility issue fixed. This is the latest release in March. Now they have introduced the accessibility help dialogue. So it's an extra little tool that a user can call in and they'll see all the shortcuts specifically for their operating system if they're on Mac or Windows. And this particular issue has been already, this particular release of CK Editor is already on Drupal 10 or Drupal 11 branch. So it will be released in the next minor release of Drupal or you can just get the patch from the core. So if we go back to Drupal and accessibility, this is one of the big major focuses of Drupal. There's a really comprehensive documentation on Drupal, Drupal.org website about accessibility and commitment to comply. There is all the bugs are being tracked. There's a lot of fixed bugs, a lot of active issues still in the queue. There's also an interesting feature as accessibility office hours. So if you have a couple of questions to ask professionals in America or anyone in Drupal.org, they run two months, every two months they're on meetings where you can actually ask questions and show your project and they will recommend how you can overcome any issues that you might have. And there's also coding standards and best practices for developers. How can you create the best accessible controls? So I ran a quick test on the CK Editor 5 in Drupal because every implementation is different and maybe CK Editor by itself is really good, but in Drupal it might have some issues. And there are a couple of issues of course. So first one is use of color again. So this is just to indicate that something is selected. It's just slight change of color. And there is an issue for that and it has been fixed and now it's already merged into the core. So next minor release, we might actually get of Drupal, you will get this functionality, this fix. The next one I had to do with the voiceover. So when you have your voiceover on, it reads out all the labels on the form fields and it tells you what sort of which, more defined which filled your editing. And with CK Editor 5 it just reads out editor-editing area main. I don't know, I have like a dozen of WYSIWYG editors on the page in this particular. So for the user who needs to actually know on which particular field they're on, it will be a bit problematic. And there is an issue in the issue queue for CK Editor for this particular item because they don't set the area label to the label of the field. It was there for CK Editor 4. And there is a Drupal core issue to just say, hey, I have this label just pasted into the CK Editor. So after that, if you apply this patch you will actually get the proper text label for the CK Editor. So another issue fixed. Anyone knows what the magic keyboard shortcut to CK Editor 2 bar is? And where do you find out that? So when you enable it, there is like documentation from the Drupal core, from the modules. So not very accessible. So why not just have it under just there where you've got your CK Editor so that you can see that there is a help available. Just make it as a configurable text. So TinyMCE, for example, has it on the default configuration as well so that you can have it as a quick help. And there are a couple of extra modules that you can install for CK Editor 5 for Drupal to make the editing experience better and better accessibility. So there is a CK Editor abbreviation just to create more semantic tags to your CK Editor. Editor Advanced Link where you can add extra attributes to the links open a new window or a title if it's an image link, for example. Interesting one, find and replace. So in particular, editor you can click find and replace and it will just replace everything. You can't really do it within a browser. And also CK Editor word count. So it will show you how many words, how many characters are in your editing. And you can build the accessibility into your plugins. So just use other labels. Don't just use color to indicate features or functionalities or states. And always test keyboard navigation. And accessibility by design. So this is a really quick guide on how to build the accessibility into your workflow, into your development and design. So when you start a new project in the discovery stage, find and define what's the level of compliance. Which tools, which environments you will be using and train accessibility specialist champion in your team. In the design stage, make sure your designers and UX specialists know the accessibility guideline levels. Especially adaptable, use of color, contrast, hover and focus state and visible focus. Lots of designers think that underline is not beautiful or outline when the focus is not beautiful. So they remove those. And this is something really easy to fix during the design stage. And adaptable is how does it look on mobile? How does it look on desktop? Just the design needs to be described. And once those things are solved, the developers don't have to go back to designers and say, hey, this color is not proper contrast. Which shade of yellow should they use instead? In the development stage, educate developers about accessibility levels. Add that to definition of done. So color, keyboard, focus. Perform accessibility testing on different platforms with lots of different tools. And develop accessibility policy. So lots of companies or lots of government organizations do have accessibility policies. So it's basically just what's your level of compliance? What's your commitment? And any contact details so that if anyone who has any issues might contact you and say, hey, there's something I can't do with or use on your website, can you fix it so that you can actually address the issue? And in the development stage there are a couple of modules that you can have a look at and see if you would like to implement them. So that's an automatic alternative text which uses AI. So you need to subscribe to some sort of service. Block area landmark roles. So if you have blocks, if you use blocks you can actually set the role on the block. So if it's a role search or role article or sidebar and there is also a keyboard shortcuts Drupal module where you can press command S and it will save. And at Go Live just you will be pretty much set to go live. Just do your final compliance reports and publish your accessibility policy. So to recap, we've got quick wins when you design and develop. Keep in mind color, keyboard, name, role, value, just making sure labels are there. You can navigate with keyboard and the colors are there. Simple. So during this presentation there were two Drupal core issues fixed, two Drupal core issues reported two CK editor five issues updated. Accessibility documentation updated for Drupal and no animals were harmed. And if you got any questions ask away and all the resources from this presentation are available on this GitHub help page. Good puzzle.