Making Content Creation Tools Accessible
•Als PPTX, PDF herunterladen•
0 gefällt mir•59 views
Did you know that an Undo button can be an accessibility feature? It is if your product is a content creation tool. Accessibility is as important for your admin and content creation tools as it is for front facing products. If you've ever wondered what content creation features are useful to people with disabilities, or how you can help your creators to easily make more accessible content, then the ATAG (Authoring Tools Accessibility Guidelines) standard is what you need. It's a bit different than WCAG in ways that are useful for web apps and software. Using ATAG as a guide, this talk will walk you through an accessibility features list to help refine your requirements and prioritize your backlog. The right preference settings, keyboard shortcuts and documentation in your app can help everyone build a more accessible web.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Making Content Creation Tools Accessible
Ähnlich wie Making Content Creation Tools Accessible (20)
Mehr von Intopia
Mehr von Intopia (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Making Content Creation Tools Accessible
- 1. Making Content Creation Tools Accessible Julie Grundy Senior Digital Accessibility Consultant at Intopia Summit 2022
- 2. needs to be built with inclusive tools An inclusive web
- 3. With guidelines and feature suggestions ATAG can help diversify your userbase
- 4. What's ATAG?
- 5. the Authoring Tools Accessibility Guidelines (https://www.w3.org/TR/ATAG20/) ATAG is…
- 6. • Any website, app or other software • Which is used to make content for the web So what's an authoring tool?
- 7. • Any website, app or other software • Which is used to make content for the web Julie's opinion: ATAG should also apply to any digital product with more UI than content So what's an authoring tool?
- 8. • Helps people with digital accessibility • Has principles, guidelines, success criteria • Hard to read ATAG is similar to WCAG…
- 9. • It's not required by law • It doesn't apply to all digital products …but also different
- 10. To make authoring tools: 1. easier to use by people with disabilities 2. more likely to create accessible content ATAG has two parts
- 11. WCAG handles access to content ATAG handles access to creation
- 12. Me on Intopia's YouTube channel https://youtu.be/I1T849ZFJ5g Introduction to ATAG
- 13. ATAG: the standard for accessibility of content creation by Hidde de Vries (https://hidde.blog/content-creation-accessibility/) Plain-language ATAG guide
- 14. What can we learn from ATAG?
- 15. Contributed by people with disabilities Feature-level advice
- 16. but meanwhile, ATAG can fill in some gaps User research is gold
- 17. • Extended keyboard controls • Error prevention and recovery • Documentation Useful accessibility features
- 21. Toolbar pattern ARIA Authoring Practices Guide: Patterns https://www.w3.org/WAI/ARIA/apg/e xample-index/toolbar/toolbar.html
- 22. Action Menu pattern ARIA Authoring Practices Guide: Patterns https://www.w3.org/WAI/ARIA/apg/e xample-index/menu-button/menu- button-actions.html
- 27. Extended keyboard support Helps screen reader users and people with impaired dexterity navigate large amounts of UI efficiently
- 28. Error prevention and recovery
- 32. Hands-free coding Josh Comeau describes how he uses speech recognition and an eye- tracker https://www.joshwcomeau.com/blog/ hands-free-coding/
- 39. Helps people with impaired dexterity and with attention or memory deficits Error prevention and recovery
- 40. Documentation
- 41. Two types: 1. How to find and use accessibility features 2. How to create accessible content Documentation
- 49. Documentation Helps people with disability find and use your accessibility features, and helps all of us make more accessible online content
- 50. Making accessible content We need accessible tools if we want people to make accessible content. ATAG can help you make your products accessible to everyone.
- 51. • @stringy • @Intopia Let's talk! Making Content Creation Tools Accessible Julie Grundy
Hinweis der Redaktion
- Today I'm going to be talking to you about how to make your content and admin tools more accessible. We want to do this because…
- …the future of the web depends a lot on the diversity of the people building the web. It shouldn't just be built into walled gardens owned by giant corporations. The web is best when it connects diverse people with different heritage, incomes, abilities. Not that I'm not grateful! When it comes to diversity, my particular area of interest is accessibility. Tools! Because PWD don't want to be just consumers.
- So today I'm going to show you the ATAG standard, which is specifically for content creation tools. Then I'm going to give you some feature suggestions based on ATAG, which you can apply to just about any web app or software even if ATAG isn't an exact fit for your needs.
- Hardly anyone has heard of it
- It's a standard, by the Web Accessibility Initiative at the W3C. You've probably heard of the Web Content Accessibility Guidelines, this is a similar thing but for authoring tools. Which raises the question…
- - Pretty much any website, app or software that can be used to make content for the web. VS Code, Canva, TikTok, Twitter, half of Atlassian. All these really powerful apps which deserve to be made accessible in the broadest sense of the word.
- My personal opinion though: any app with more UI than content. Which includes business and productivity tools. PWD often find inaccessible business software a major barrier to employment, can't use the same tool as everyone else in the office.
- (describe slide content)
- (describe slide content)
- ATAG divides up all the success criteria into two parts: Part A and Part B
- I'm not going to go into all of the success criteria today. You know how to read documentation!
- But if you feel like ATAG is a perfect fit for your organisation, I'm going to direct you to some deeper dives into the standard. Recording of a webinar I gave earlier this year…
- Check out a really great blog post by Hidde de Vries, who spoke at the Web Directions Triple A conference, which puts all of the guidelines into plain language, much easier to read than the standard itself.
- What I'm going to do now is looks at what we can learn from ATAG even if it's not a perfect fit for your product. Because another big difference between WCAG and ATAG is that ATAG has a lot more feature-level advice in it. For example: alt text.
- So if you squint at it the right way, ATAG contains within it a list of the most common features that people with disabilities want in complex interfaces.
- Now obviously you should be doing user research before you begin building anything new User testing before launch Intopia provides this, and any accessibility practitioner would be thrilled to help you out But there's not always budget, or you've already built it, or you've got a long list of features and aren't sure what to make top priority What I’m suggesting is that ATAG can be used as a bit of a guide for what features people with disability are going to ask for.
- For me, the best feature suggestions from ATAG fall into three main groups. I'm going to show you examples of these features from existing products; not unusual stuff, we just often don't realise that these are accessibility supports rather than just nice-to-have These groups don't map exactly to specific success criteria in ATAG, this is my own grouping based on talking to clients we've done ATAG work with
- Let's start with extended keyboard control. Our basic WCAG requirement is that everything must work with the keyboard. If you have a nice ecommerce site, etc then you want navigation and some forms to work with the keyboard. But when we get into authoring tools, all of a sudden we've got a lot more UI to consider. Sometimes the whole app is just one big user interface.
- I've picked VS code as an example here for 2 reasons: firstly Lauren; secondly it has a lot of features I think fit into the ATAG way of doing things. (Describe screengrab)
- (Describe new screengrab: sighted keyboard user, screen reader user would have a different experience. Imagine if you were writing some HTML then wanted to get into the Edit menu.) Notice though, that there could have been many many more tab stops for a keyboard user. (describe). The reason for this is that VS code uses a lot of what accessibility folks call a Toolbar pattern, which is much more common on desktop software than the web (describe)
- You can get a deep dive into the toolbar pattern in the ARIA authoring practices guide, the APG. If you've heard me talk at all about accessibility, you'll have heard me mention the APG before. This has a full description of how to make an accessible toolbar, with all the markup and keyboard listeners you'll need, and a demo for you to play with.
- Another really useful pattern for providing extended keyboard support is called an "action menu" pattern. That's for when you have a menu of tools rather than a menu for navigation. Again, deep dive into the details.
- Something you might not think of as providing keyboard support is a search feature. But it helps you jump to exactly the spot you need in what you're making. VS Code has some features which are specific to code, you would obviously want to adapt that to add features which are specific to the type of content your users are making.
- - Another thing you might think of is keyboard shortcuts. VS Code has a heap of these, and they're all editable. This is particularly helpful for people with disabilities, because they need to avoid conflicts with the keyboard shortcuts built in to their screen reader or other assistive tech software. AAA, but gets mentioned again in ATAG
- Let's just change things up a bit from VS Code for a bit. Because Canva is a web app, it can use landmark elements in code to organise the interface. (describe screengrab) These work well for screen reader users, who can use their standard landmark shortcuts to jump from one area of the interface to another But these aren't usually exposed to anyone who isn't a screen reader user.
- Another method of extending keyboard support is to let people choose which parts of the UI they have to navigate through by putting it inside panels and tab groups which can be collapsed or expanded. (describe) Again we're just letting people have more control and choice than we would for a site which was mostly about consuming content.
- - Overall, what we're aiming for is to help people navigate large amounts of user interface in the most efficient way possible. Any feature you're considering which does that job will be a huge plus for PWD, and a nice set of shortcuts for everyone else. These sorts of features tend to be the sort of thing you build once then just have to do a bit of light maintenance on over time.
- For me, fixing a mistake is a little bit of a pain in the arse. For someone with a disability and/or using assistive technology, it can be a huge time sink. But all of the features I'm about to show you are really common ways of making mistakes easier to deal with, so I want to make sure you don't forget to consider them in your roadmap.
- One of the best ways to prevent mistakes is to allow people to save templates or snippets of things they'll want to re-use frequently. Canva is probably my favourite example of this, it has pre-made templates but allows you to save your own too. This way, PWD only have to put a lot of effort into making something correctly the first time, and then can re-use that thing later Figma, Confluence, sharing templates with community
- In the talk description I mentioned the humble Undo button. An Undo command is easily the most useful accessibility support you can provide in a complex app. Figma has quite a common setup (describe).
- Figma also takes extra care by giving you a warning before you do any destructive tasks, like deleting things. Again we're just giving people a chance to recover from a mistake before it's too late. Now, this might not seem like much to you, but when reaching the controls is difficult it can be such a time-saver.
- You might know Josh Comeau from his work at Gatsby or his course CSS for JavaScript Developers. But you might not know that for about 2 years, he wasn't able to use a mouse or keyboard due to a repetitive strain injury. He switched to using a speech recognition tool called Talon, which is designed for coding tasks, and a Tobii eye tracker. When you use an eye-tracker, each click takes two actions – you have to focus on the item to zoom in so you can only see one of item, before you activate the click.
- Now coming back to Figma, imagine you deleted this file by clicking the red delete button, then immediately realised you'd made a mistake. Maybe you were distracted and got the wrong one. If you were using an eye tracker, you'd have to do four actions to undo that mistake. Focus on the Edit menu, activate it to open it, then focus on the Undo item, activate it to undo.
- But Figma has made this easier by surfacing an Undo action specifically for that destructive action, just in case. It might seem like they're being overly cautious, but for someone using eye-tracking, they've just halved the number of actions needed to recover from a mistake from four to two, by making it so you don't have to open a menu first. Don't underestimate the power of making Undo available everywhere!
- Most software gives you 10 or 20 Undo steps, but if your content creation tool makes things which are worked on over time, we get into the idea of versioning. Someone with an attention disorder or a memory deficit could go quite a long way before they realise they've headed in the wrong direction. Confluence and WordPress let you do this, but I feel like it's becoming less common. Letting people go back to earlier versions or snapshots of their work allows them to recover from that kind of bigger mistake, without having to learn Git just to write a blog post.
- Another feature you might not realise is an error prevention tool is any kind of sharing or export feature. If someone with a disability has gone to a lot of effort to make something, letting them get it out of your software and re-use it somewhere else means they don't have to recreate all that effort and with all of the potential for mistakes again. Obviously what kind of exporting you offer depends a lot on what type of content you've got, but being able to change formats or embed things in a new location can go a long way to making life easier for many people.
- One of the obvious ways of preventing errors is to give people a spellcheck feature. You should absolutely customise it to the kinds of content your tool makes, if you can. We can include code linters in this category as well. I've lost count of how many times an automated accessibility checker has told me off because I wrote "area" hidden instead of "aria" hidden.
- My last feature suggestion from ATAG in this group is kind of a stretch goal, an extension of the idea of spellcheckers and linters. If people are investing a lot of time making something, encourage them to make it accessible. MS Office is good (describe) Again, customise (slides vs page title here)
- So for error prevention and recovery we've got a lot of features which seem small, until you're the one who has to build them. But don't forget to include them, because they can make the difference between your tool being accessible or not.
- Is documentation a feature? It's one of the things people consider when choosing a CMS or other software Could have the most accessible, but if no-one knows then what's the point? For accessibility we need two types of documentation
- Firstly… Secondly…
- - Figma does a great job of the first type in their keyboard documentation. They've got a page all about keyboard shortcuts, and notice how it's part of the Getting Started area, not tucked away in a separate accessibility section. - they've aimed it at anyone who might need this feature (describe)
- Secondly we want to make sure that everyone knows how to use your tool to make accessible content, whether they know much about accessibility or not. This screengrab here is from WordPress again, of the modal window that pops up when you add an image to a blog post.
- They've included alt text in with all the other details and settings for the image, again not hiding it in a separate accessibility area.
- They've used inline help text to tell you how to use the field, with a link to learn more, and what to do if you don't need alternative text for that image. So if this was the first time you'd heard of alternative text, you could easily find out what to do.
- Lower down though, we've got a field that confused me. We've already got alt text, a title attribute and a caption for the image. What could description possibly be? This is where documentation helps even experienced accessibility folks like me. I was worried that whatever I put there would override my alt text, or break something if I left it blank.
- But I was able to go to the documentation for the attachment details modal, and find out that the description is purely for my benefit, and helps me organise my media library of attached images. Awesome, no worries then.
- One last thing to consider as part of your accessible documentation is making sure that the examples you give in there are also accessible. Because we know for sure that people are going to just copy and paste your samples straight into their own work, right? So let's help out PWD by supporting creators to make accessible content even they don't know what they're doing yet.
- So documentation is what helps PWD use your tool, and helps everyone make more accessible stuff. It's not your responsibility to force people to make WCAG compliant things, but you can make it a hell of a lot easier for them and by doing that, you'll really raise the bar for accessible content online.
- I hope you're intrigued enough by ATAG to give it more attention. I really think it's a great standard for anyone working on a product which creates content. But even if your work isn't on authoring tools, I hope you've found this a useful guide to features that people with disabilities will rate as more important among the many things you could be building.
- Before I finish, I'll just say that everyone I meet at a WD event loves making stuff, so I think you'll get what I mean when I say that the people here are building the future of the web. We have a lot of power here. So let's make the future more accessible than the past, by making the tools we use for work and hobbies into things which anyone can use. If you've got any questions about how accessibility might apply to your work, come and find me for a chat – I love talking about this stuff!