Making Content Creation Tools Accessible

Seem to have my voice after two days of conference, so that's good.

Yay.

As thank you for the lovely introduction, Sarah.

Today I'm gonna be talking to you about the how to make your content and admin tools more accessible.

If you want to follow along with the slides on your own device I have them on the notist website, which is noti.st . And my screen name there is Stringy.

And in that there should theoretically be a link to the slides.

Failing that they are also on the Intopia SlideShare, but SlideShare appears to be now full of ads.

Yikes.

The reason we want to make our content and admin tools more accessible is because, and I have not turned on my little doo-dah here.

Yeah.

Is because the future of the Web depends so much on the diversity and inclusivity of the people who make the Web.

Each the, Web should not just be built into these walled gardens owned and operated by giant corporations.

Not that I am not grateful for the work of giant corporations.

I use many of their tools.

It's just that at any moment they may get bought out and tanked by a random billionaire.

Not that I'm bitter but also because people with disabilities, like anyone else do not want to be just consumers of the Web.

They want to be creators.

They want to be employees and employers to have hobbies online, to share cat memes everything that everybody wants, right?

So in order to do that, You need to be able to use the tools that make the web.

So what I'm gonna show you today is a little bit about the ATAG standard.

It is specifically designed for content creation tools and then I'm going to, once I've done that, I'm going to give you a few feature suggestions.

These aren't specifically from ATAG but they are extracted from my times working with ATAG with clients and the things that often ended up being the biggest barriers to access.

So you are probably wondering at this point, what is ATAG?

No one has ever heard of it or hardly anyone.

That's okay.

You are not alone.

ATAG stands for the Authoring Tool Accessibility Guidelines.

It is a W3C standard.

And this then raises the question.

You may be wondering authoring tools.

What's an authoring tool?

According to this standard, an authoring tool is any website, app, or software, which is used to make content, which will be delivered on the Web.

Now, my personal opinion is that ATAG is useful for more than software, which just makes things which go on the Web.

Also, how many things do we make cannot be put on the Web if we want to.

It used to be that video software wouldn't be considered something that you would make video and put it on the Web, but now Web speeds have increased, we can do this.

Word documents used to be, oh, you technically view them on the Web, but now we have Microsoft online and Google Docs.

Ultimately everything ends up on the Web, so why not apply ATAG to all of our content creation tools?

I feel like ATAG has a lot to offer as a standard to any product which has generally more UI than content in it.

I feel like even if it's not the the perfect fit standard for you or for your product, you will probably get a lot of value out of getting like a basic understanding of it anyway.

Now similar to WCAG, ATAG is similar to WCAG in that it's designed to help people make digital products accessible.

It's broken up into principles, guidelines and success criteria, and it is hard to read because it is written by an international committee of people trying to make a standard, which can be interpreted by lawyers and browser authors.

So hard to read.

It is different from WCAG though, in a couple of key ways.

Firstly, it is not required by law.

It is a purely optional standard.

It's there to use if you need it, if you feel like it's, worth your while, and it doesn't apply to all digital products, as I've been saying, it's content creation tools.

If your tool creates content in some way, it applies.

If not, it doesn't, it's probably not gonna have a lot of value for you there . Because of this, ATAG has two parts.

All of these principles, success criteria, and guidelines are split up into part A and part B.

Part A is concerned with making the tool itself easier to use by people with disabilities so that they can create, and be creators.

and part B is about making the tools more likely to actually create accessible content supporting the broader generation of accessible content.

This is partly why I love ATAG , is because I am like, ... if we actually started making more accessible content from the start, instead of making it inaccessibly and then going, whoops, we've done a WCAG audit and it doesn't quite work, let's just retrofit some accessibility onto that.

What if we actually had more people with disabilities involved in building the Web?

What if we had more people who didn't know anything about accessibility, subtly encouraged and supported in making accessible content?

So WCAG handles access to content, ATAG handles access to creation.

Is the general kind of split that we have here.

Now, I'm not gonna read you a specification because you, you know how to read documentation.

That's fine.

I will direct you though, if you find that this is a standard that you are like, yes I need some ATAG in my life, I will direct you to a deep dive that I did earlier this year as a webinar.

It's on the Intopia YouTube channel, and it's called , appropriately enough, "introduction to ATAG".

Yeah, like I'm, not much for creative names I'm like, yeah this, talk is about making content creation tools accessible.

That talk was about an introduction to ATAG.

The other thing that I would love to direct you to is there is a sort of a plain language.

Guide to ATAG, written by Hidde de Vries, who is one of the few people who has done a lot of work on ATAG.

So I really do trust his interpretation of the guidelines.

Highly recommend checking that out.

He also made, and I have forgotten to put a slide for it like an evaluation tool for ATAG.

So if you weren't sure if you needed an ATAG audit, you could use this as a bit of a first pass yourself.

And it's done in the browser.

It's nice and easy.

What I'm actually going to do with the rest of my time is talk about what we can learn from ATAG, whether or not we have specifically a content creation tool.

Maybe your tool has a little bit of content creation.

Maybe it's got a little rich text area or something.

Maybe it is a content creation tool but you are not sure what features to prioritize.

So what I've been doing over the last few years doing ATAG audits is kind of what I perceive within it is that ATAG has a lot of feature level advice compared to WCAG.

Because ATAG was written with contributions from people with disabilities, if you squinted this the right way, you get a list of recommended features from people with disabilities.

I wouldn't want to rely on this, right?

Like user research is our gold standard.

Always user research, co-design with people with disabilities.

User testing before you release with people with disabilities Intopia offers this as a service, but literally any accessibility practitioner here or elsewhere- so Gian, Amanda was speaking earlier.

Brie's here.

Everybody from the Center for Inclusive Design will, be thrilled to help you find people with disabilities to do user research with.

However, not everyone has budget for that.

So if you don't, ATAG can fill a few gaps here or tide you over until you can persuade the boss of the need for a little budget for some user research.

I tend to group these features into sort of three loose categories.

These this, is all me coming up with these ideas based on experience.

No one else has documented these groups or anything, it's just what I reckon.

But what I reckon is extended keyboard controls, error prevention and recovery and documentation are the areas of your feature list that should get the most love if you are trying to prioritize accessibility.

So extended keyboard control.

What I mean by this, oh, slides, there we go.

What I mean by this is that WCAG has this basic requirement-oh, everything should work with a keyboard.

Of course it should.

If you have a nice e-commerce site and it's got some products and then you've got a checkout, you need, people need to be able to navigate using a keyboard.

They need to be able to use a fancy form with a keyboard.

And as we heard in Gian's talk earlier that gets complicated once we get onto a mobile device.

Insert Gian's talk here about , like just sidebar that and talk about mobile testing methodology.

ATAG says, sure, but just working with these things is not enough.

Because this here, what I've got here on the screen is just a slightly enlarged version, slightly bopped up text size of my standard VS Code Layout.

You can see here we've got a lot of UI.

We've got that menu along the top-file, edit, selection.

Down the left hand side, we've got the file explorer open with all of the files plus some little accordions in case you wanna look at it in a different way.

Along the right hand side, we've got mini map.

Down the bottom we've got a terminal window.

In the middle, we've finally got the actual content I'm working on, which in ATAG language we is called the editing view, and even that has more navigation along the top because we've got tab panels for the other files that I might have open.

Just having everything work with the keyboard here is not going to cut it.

What I've done here is the same screen grab, but I have now turned on Microsoft Insights and used their tab path visualizer.

So starting from the editing area, number one in the middle, and then we zigzag all the way through, all through that top menu, that left menu over to the mini map back into the middle with the editing view, you'll notice the terminal doesn't get hit.

That's 14 tab stops.

For someone who may have wanted to just go up to the , edit menu and then hit an undo button or something, and then they have to tab, to get back to where they were.

The interesting thing here is that fourteen's a lot, right?

If this was a website, I would absolutely want to skip menu skip to editing view for that, right?

It could have been worse, right?

Because notice there is only one tab stop for that top menubar.

That the sidebar there has the most, because that has the tabs and panels hiding different parts of the interface.

The mini-map only gets one.

So the reason for this is that VS, if we had actually made every single one of these things focusable with the tab key, you would have I think I counted this at some point, it was like 57 tabs or something, and that depends on how many files you've got in your file Explorer, right?

This is because VS Code though has used the toolbar pattern.

The toolbar pattern is just the word the, sort of accessibility word for this thing where when you tab to a toolbar, your next tab will take you away from the toolbar and to the next large chunk of content, which is great.

If you want to navigate within the tool, if you reach the toolbar and you're like, yes, this is where I wish to be, something I want is in here, then you use the arrow key.

And so this enables people to sort of leap through the interface easily.

Focus in on the bit that they want, navigate within it, and then use the tab key to bypass the rest and get back again.

The ARIA Authoring Practices Guide is my love-hate relationship with accessibility is with the ARIA authoring practices guide.

Really great patterns, really thoroughly described, with some demos that I really completely want to rewrite the JavaScript of.

They work, right?

They're demos, they're for playing with.

If you look at that and you say, yes, I see what you're trying to do there.

I'm gonna completely rewrite it in React or whatever.

Lovely.

Go wild.

Another authoring pattern that's really useful when you've got a really tool heavy UI is the action menu pattern.

And again, this is in the ARIA authoring practices guide.

And this is for a menu where the items in your menu aren't navigation.

They're tools.

They may modify something on the page.

They're related.

So you've put them in a little, action menu like edit, delete, restore, that kind of thing.

And you can make this much more keyboard friendly and make it much easier for people, for screenreader users and sighted users who rely on the keyboard to be able to access this.

Coming back to VS Code again with this screen grab.

Something that you might not think of as providing keyboard support is a search feature.

In VS Code here, this particular one I've highlighted that you can use regular expressions.

What this search feature does is it's not just searching the content that you're making, which is great, enables you to jump around within it.

They've customized it to the specific needs of that content.

Again, that's not something that's specifically ATAG requires.

ATAG is just do you have a search?

Cool.

I think, but the, times where I've seen this work really, well has been when that search is customized to the content that people are creating.

And you would know that, you know that better than you and your users will know that better than ATAG knows that anyway.

So that's one.

Another one that you might not think of or that you, would think of but you wouldn't think of is keyboard shortcuts.

Again, because it's UI, having these keyboard shortcuts to jump around from one location to another gives people options and ways to do that.

However, the problem we have with keyboard shortcuts is that sometimes they end up, sometimes, quite often they end up conflicting with the keyboard shortcuts of the assistive technology.

So for a screen reader user, they're using the H key to jump around by headings.

You cannot be having that with your keyboard shortcuts, there'll be a conflict.

The wonderful thing here is that VS Code uses mostly are multicharacter keyboard shortcuts, which is great, and that is suggested by WCAG in our AAA category.

But making them editable is where I think you can really plus your, accessibility.

Let people decide, "you know what?

This keyboard shortcut keeps conflicting with my specific keyboard shortcut.

Let me just edit that to something that I can use." Providing people with the option to, adapt if need be.

But you've given them some sensible defaults to begin with.

Changing away from VS Code for a little bit, we have a Canva screen grab here.

Because Canva is a Web app, it can use the landmark elements in HTML.

And so that allows us another way.

This is specifically supporting screen reader users who have landmark shortcuts available to them.

So here I've got the screen grab of Canva in the, editing area.

It's, I've used, again, the Microsoft insights to ind of, it's hard to see on this, but you can see the colored dotted lines, one around the header for the banner area, one around the editing view for the main footer for the toolbar at the bottom.

And on the side we've got the complimentary region, which has got all of your little tools.

Now.

Again, this just lets you jump around.

It's a lightweight kind of way of doing things.

It's not a substitute for other methods of UI navigation.

But it can be a really nice supplement and you're probably using these elements anyway, so why not think of them in this way?

Think, are you using them usefully in terms of how that would be great keyboard navigation.

My final bit of extended keyboard support would be to let people choose which parts of the ai, the ui, they, the ai, the UI that they want to navigate.

CMSs are generally quite good in this regard, so this is a screen grab of a blog post on, my website in WordPress.

You'll notice at the bottom of the sidebar, it's got a collapsed menu control.

Personally I would prefer that to be at the top, but I can see why people might not do that.

We've also got the sidebar, all the tags and the categories and all of this.

You can close them up.

So if someone's working on a blog post over time, they don't actually have to navigate through all of this interface every single time.

They may be like, I'm just working on editing the content now.

When they're done with that, they can open up these panels and start, oh yeah, let's add some tags, let's work out a category.

But just letting people have that choice and control is what works best.

So extended keyboard support is generally we're, aiming to help people navigate large amounts of UI in the most efficient way possible.

I've given some suggestions for things that I believe are really good examples but honestly, any feature that you are considering, that allows people to jump around quite quickly and efficiently will be really, helpful for people with disabilities and probably a source of nice shortcuts for everybody else.

These sorts of features tend to be the kinds of things that you build once, and then you just have to do a little bit of light maintenance over time.

Don't quote me on that, but generally in my experience, that's what I've observed.

For me, fixing a mistake is a little bit of a pain in the ass.

For someone with a disability and using assistive technology it can be a huge time sink.

Okay, so this is why error prevention and recovery is so important.

Anything we can do to make that easier is wonderful.

So I don't want you choose...

a lot of these things that I'm about to show you seem quite small, and I wanna make sure that you don't skip over them in your priorities, in your roadmaps, in favor of things that kind of are cooler and more exciting.

When you have made a mistake and you don't know how to fix it, nothing is cooler and more exciting than having an undo button just magically appear.

The first way the, best way to prevent mistakes is to make sure that people only have to create things once instead of repeated work.

I've got Canva again as an example here.

They have many pre-made templates which you can edit and save and reuse.

You can make your own template and save and reuse it.

So all of the effort that goes into making something correctly only needs to happen once.

And then all of your mistakes, you fix all of those once, and then you don't have to worry about it ever since.

Lovely.

Confluence and Figma also have similar features.

I don't want to imply that Canva's the only one.

And all of these have sharing community areas so people, if they've made something, can be reused by other people as well.

I've mentioned the undo button.

I am a big fan of the undo button, as you can probably tell.

I just honestly think it is just one of the most useful things.

Maybe it's just because I make a lot of mistakes and I'm like, even like I'm speaking to people and I subconsciously try and hit Control Z with my hand and I'm like, that doesn't work for speech.

Okay.

But if you're doing a, if you have a complex app, right?

Undo is so important.

This is a screen grab of Figma.

It's a very standard kind of setup.

You've got your menu, you open that up, you've got an edit menu, you've got an undo right at the top, and it has a lovely keyboard shortcut using the standard shortcut, which will pretty much control Z will pretty much undo anything in most software.

Now, Figma have gone on a little further.

What they've also added is an ATAG approved feature, such as, before committing any destructive actions, ask people, are they sure give them an opportunity to go, no, actually I did not want to delete this file.

That was a mistake.

Awesome.

Lovely.

That again, it might not seem like much, but when someone has pain in their hands or arms and they're trying to, or they're using assistive technology, it can be really like quite, quite a lot to recover from if you delete a file that you didn't mean to delete.

Some of you may know Josh Comeau from his work at Gatsby or from his, he's recently done a CSS for JavaScript Developers course, which is really highly rated.

What you may not know is that for two years he was relying on speech recognition and an eye tracker to do most of his coding.

He's written a really fascinating blog post where he digs into the detail.

He uses a speech recognition tool called Talon, which is specifically for programming and allows you to set up common programming needs, like you can set up verbal shortcuts for camel case or snake case shortcuts for functions you write all the.

And he uses a Tobi eye tracker instead of a mouse.

So for Josh, the reason he was doing this is because every time he was using his hands with a keyboard or mouse, he was getting burning pain in his arms.

It's gonna put you off a bit.

So for Josh or someone in the same situation as Josh, this kind of, this Figma where you end up with this Redoing this delete, right?

Imagine if you then went, yeah, delete this file, and then you think, oh, I didn't mean to delete that file.

I meant to delete this other file.

Not speaking from personal experience at all.

Figma does this really lovely thing where, again, after an important destructive action, they will surface this undo again.

Give you a little confirmation message, which is lovely for our screen reader users to hear, yep, that did get deleted.

Excellent.

But there's also an undo button in case you're like, Ooh, that did get deleted.

Doh.

With eye tracking software, you have every action becomes doubled.

In order to click on something, you must focus on it first.

It zooms in, brings it into to confirm that this is the thing you want to click, and then you click it.

So that Figma menu.

Is currently behind, with the undo button, is currently behind that, an icon in the top.

So that would take six clicks to open.

It would be click on the menu, open that open, click on the menu, the edit menu, wait for that to open.

Focus on the undo, and then click on the undo.

And then finally you get to undo your deletion.

Here they've just gone, oh, you could just have two if you're using an eye tracker . So you can see the, just the quantity of actions needed has been reduced so much.

Most software gives you 10 or 20 undo steps.

But if your content creation tool has things, makes, things that are worked on over time, we are starting to get into versioning territory here.

Any versioning that you can provide that is suitable for the kind of content that you're making is great.

I've got a screen grab here of page version on Confluence.

Word has some, Google Docs, has some, WordPress has some.

There's so many snapshot features are another way of dealing with this.

Any of these let people recover if they've gone a long way down the wrong path of a mistake.

So someone with ADHD someone with memory issues may end up forgetting the purpose of what they were making and then realize.

Oh no, I need to go back.

That's okay.

You've got a history there.

They can go back to the last good spot and recover from that.

And you shouldn't have to learn git just to write an essay or a blog post or something that's just overkill.

Another feature you might not realize is an error prevention tool is any kind of sharing or export feature.

You've made it once, you could go and make it again elsewhere with all of the potential for mistakes again.

But why would you, if you've just got this lovely, accessible tool that lets you make things easily with lots of good error prevention and recovery, you could take that wonderful thing you've made and then just use it somewhere else.

Again, other ways of doing this, some examples: JIRA , you can export to Excel.

You can embed a YouTube video in your website.

Anything that allows people to share mediums is lovely.

One of the obvious ways of preventing errors is to give people a spellcheck feature.

You should definitely customize it to the kinds of content that your tool makes if you can.

We can also include code linters in this kind of category.

I have lost times the number of times that an automated accessibility ... tester has told me off because I've written area-hidden instead of aria-hidden.

Linting, it's great.

And since we're talking about linting, I will introduce a little stretch goal, an accessibility checker.

This is definitely a feature that I wish more content creation tools would include.

I've got a screen grab here of the PowerPoint when I think all of the Microsoft Office accessibility checkers are quite good in that they tell you what the problem is, link you to it so that when you click on that error, it opens up the exact spot for you, tells you how to fix it.

And they customize the language away from that technical kind of WCAG stuff to things which are relevant to the people using the tool.

So here, instead of saying, oh, you don't have a page title, it's got, oh, you've got a missing slide title that's more relevant for a PowerPoint.

So error prevention recovery helps people with impaired dexterity and people with attentional memory deficits.

These again, are, seem like small features until you were the person who has to build them.

But please don't let that let you overlook these and bypass them.

My, my last, group, and I will try to hurry is documentation.

I do not know if documentation is a feature or not.

I assume product managers know this thing and they will tell me if I am wrong.

But it is one of the things that people look for when they're choosing a CMS or other content creation tool.

They're like, I don't know how to make stuff.

How do I make stuff using your tool?

Please tell me.

So for if you have a really accessible tool and people don't know how to use it accessibly.

If people with disabilities don't know that you have the features that will support their needs, why would they use it?

You have to let people know about this.

So for accessibility, we need two types of documentation.

We need to know people with disability in particular need to know how to find and use the accessibility features that you've provided.

And everybody needs to know how to use your tool to make accessible content.

Figma does a really great job of this first type.

I really, I smiled when I saw this example.

I was like, yeah they have so many keyboard shortcuts and quick actions, and they have, you'll look at the breadcrumbs there.

It's in the getting started setup section.

It's not a separate, oh, here's the separate but equal area of documentation for people with disabilities.

It's I don't know.

You might wanna use this as they say right there to save you from any unnecessary clicking and scrolling.

Don't really care why you need that.

They're just like I don't know.

You might want some cool, we'll do this.

So I I really like this.

It's integrated and it's friendly.

The second type of using the, tool accessibly, I'm coming back to a WordPress example here and here I've attached an image to a blog post and WordPress gives you like an attachment details modal.

And I know because I am an accessibility person that I need to go in here to check the alternative text.

Which is there.

Lovely.

They've, again, we've got this integrated with all the other file details.

It's not separate.

Oh, here's the accessibility for the image separate from where the image is saved or what file size it is.

It's all integrated.

They've also used the help text underneath the instructional text to tell you how to use the field.

And I could again, my definition of documentation is pretty loose.

I think if it's, text and it's telling you things.

Yeah, that's documentation.

Inline help tells you how to use this field.

It tells you what to do if you don't want to use the field like this is decorative.

I have nothing to say about this image.

Cool.

It tells you what to do and it gives you a link that takes you off to somewhere else.

If you are like, what even is this?

I'm not on a deadline.

I would like to follow the rabbit hole and find out what's going on here.

Excellent, sorted.

But documentation has another purpose as well, because here I am, I'm like, yes, here is my alternative text and my title and my caption.

Lovely.

What's a description field?

If I leave this empty, will anything bad happen?

If I fill it in, will it override my alt text?

I don't know.

I'm an accessibility expert and I'm like, what's happening here?

Luckily, WordPress has some documentation which handles this, and so I was able to look it up and find out what each of the features of the attachment details modal does and find out that, oh, that's there to help me understand what my, help me choose among my various things in my media library.

It's not exposed to the user at all.

Lovely.

No worries.

Final thing to consider for documentation is making sure that the examples you provide in tutorials are using accessible markup and demonstrating correct accessible use.

This is something where even, I, I feel like this isn't done enough, is that even tools which create accessible content or can use accessible content, then teach people how to use it in an inaccessible way.

Here, I've just got a screen grab of the instructions for the GDS.

The government design system for Gov dot UK and they're telling people here, developers here is how to grab a date of birth input Field.

We've got a little component for that, but they've told you how to do it accessibly, their markup is accessible and they've told you exactly what each attribute is for, what purpose it serves, and how to use it wisely.

It's beautiful.

It means that somebody who does not give a damn about accessibility can still come along, copy paste this out and slap it into their own work and great.

We've raised the bar on accessibility.

You can literally set a good example for people if you do this.

So documentation helps people with disability find your accessibility features, helps all of us make more accessible content.

And that's why I wanted to give this talk today, is because we need these accessible tools.

If we want to raise the baseline of accessible content on the Web.

We need to make sure that people with disabilities are contributing and we need to make sure that we as the kind of intermediaries are supporting good practices in this way.

So I think ATAG can help you get across this.

Even if it's not the standard for you and your product, I think you can get a lot of value from it anyway.

Two things before I wrap up.

Firstly Web Directions has a training discount for everybody attending Web Directions 10% off up to three tickets on any of our accessibility training, which I should have put a link in there, but you can find it on our website.

The final thing I want to say is that, everybody that I have ever met at a Web Directions event has been someone who really likes making stuff.

So I hope you won't think I'm outta line if I say I think that we are the people who are building the future of the Web.

There is a lot of power in this room, and we can use that power wisely.

Again, like to raise this baseline it's not your job as someone, as a developer making a tool to chase after everyone and make sure that they're following WCAG guidelines.

But you can make it easier for people to do the right thing just by setting and place these like these sensible defaults, telling people, gently instructing them along their little accessibility journey.

And if they find out later that they've done something accessible by accident, then they get a nice, warm, fuzzy feeling.

They're like, oh.

I didn't know I was helping, but okay, cool.

This is what we want.

That's a lovely introduction to accessibility.

Much nicer than having someone say, your work's inaccessible, I've done an audit and it's terrible.

We have the power to make this a better experience across the board.

I hope that you will take this opportunity to do that.

That's me for now, I think we've hit the end of the, scheduled talks, and now we've got one more thing and then it's time to go.

So find me.

Talk to me about accessibility.

I love it.