Talk by Dylan Wages
Designing an accessible website takes planning at all stages of the development process. In this presentation, I will go over key design and UX elements and how to make them accessible. I will cover topics like navigation, page structure, colors, links, ARIA labels, and testing tools to help you accomplish a more user-friendly and accessible website.
Watch Dylan’s Presentation
Dylan Wages: All right, my presentation is about “How to Plan & Design for Web Accessibility.”
Let’s see. My goals–my goals today are to help you gain a clear understanding of what website accessibility means, learn about the different levels of website accessibility, how and when do you plan for website accessibility, go over website accessibility design principles and how to apply them, and also just learn about a couple tools to use to kind of gauge your kind of level accessibility of your site.
We’ll go, kind of, more in detail and I actually demonstrate those when we get to that point. Website accessibility. An accessible website is one that can be used by everyone: people of all abilities and disabilities. When thinking about disabilities, we usually think about, you know, blindness or individuals in wheelchairs or hearing impaired.
Those are kind of like, just kind of standard, what people think. But there’s–but there’s more disabilities. They come in different forms like color blindness, muscular dystrophy or sometimes a temporary disability. People don’t even think about that. Someone can have a broken arm or a hurt hand, and they will just need to navigate through a website without using the mouse and that–this affects all ranges of people.
Yeah, but just–I think we need to remove as many barriers as possible for them so we can have the same–so they can have the same access as everybody else.
Why accessibility matters.
It’s socially responsible, but just being more inclusive for as many types of people is kind of what we’re trying to do here. And it’s great for SEO, which is surprising to hear to a lot of my clients when I talk about that, why it’s great for SEO.
We’ll go over some of those later in the presentation. It allows your organization to reach more people, and by doing that, increases revenue. And that’s surprising for some of my e-commerce clients that don’t even think about, well, why does that increase revenue? So we can kind of go over that in this presentation as well. In some cases, it may be legally required to be that, and that’s true on some of my non-profits and some, like, government organizations that I have worked with in the past.
Now, we’re gonna go over, kind of, I guess the boring part of this presentation, I call it. But it’s kind of, just kind of setting terminology a little bit. It’s kind of–’cause you see a lot of terminology like Section 508 and AA and AAA and I kind of like to kind of set the bar on that. I try to keep this section short and kind of brief but it kind of helps, terminology. I also wanna preface it, I’m not a lawyer, so I’m not giving any legal advice on this, but I want you to understand that just kind of where these terminologies come from.
What is ADA compliance?
You hear this term, ADA compliance. American Disabilities Act (ADA) from 1990 is a comprehensive federal civil rights law prohibiting discrimination of the bias of disability. Title II of ADA applies to the state and local governments, while Title III applies to “all places of public accommodation.” However, both sections require organizations remove any barriers to a disabled person’s ability to access goods and services.
Now, Section 508.
Yeah, I’m not gonna quiz you on every section of this. And we had Section 504. I’m not gonna go everything but this is kind of abbreviated timeline and version of all the laws haven’t passed. So we’re gonna start with Section 508. It was amended by the Workforce Act in 1998. Requires federal agencies to develop, procure, and maintain a use of information and communication technology known as ICT that is accessible to people with disabilities, regardless of whether or not they work in a federal government.
The US Access Board established the Section 508 standards to implement the law and provide the requirements for accessibility. So it’s kind of the government’s version right now of accessibility and information technology.
A little more here. In 2010, way back in 2010, the US Department of Justice issued an Advanced Notice of Proposing Rulemaking, indicating they would intend to amend the language in Title III that we talked about a minute ago of the ADA to ensure it would also apply to the website accessibility. The Department of Justice was planning on moving forward incorporating the website accessibility guidelines, WCAG 2.1 which can be found at this link, in 2018.
However, the current administration has put that on hold. So, for now, there’s no clear ADA applies to web design, no regulations, no increase, but there are increasing numbers of lawsuits that are coming out. And one of those was found in this 2019 website app lawsuit recap report and the total number of ADA web apps accessibility filed cases reached one an hour in 2018 and held around 2019. Now, the 2019 kind of drifted down because they’re kind of waiting on the Supreme Court to decide on a hearing on the case versus Domino’s. However, one should not assume that the absence of the DOJ regulations and other guidelines or by due process defense claims website connected to a place accommodations fails to comply with accessibility requirements under ADA.
So currently, the WCAG 2.1 is kind of the benchmark that they refer all these companies right now to as far, ’cause there’s not, like, a direct law that guides them. So for my opinion, why I’m not–I’m not a lawyer, but in the future I believe Title III will be updated with website accessibility standards and eventually become US law. And along the way, it’ll be guided by decisions in cases like Robles versus Domino’s that we talked about a second ago. Also believe the Department of Justice–I also believe the Department of Justice will use the WCAG 2.1 AA as a standard benchmark in law.
In some countries, like, for instance, in Japan and Norway, they already have consequences for not meeting these guidelines, similar guidelines, if you don’t comply. In Netherlands, for example, all government-directed websites need to comply by 2020 but, like the US, they’re all pushing for legal requirements for private businesses to be–hold the same level of accessibility.
So US, I think, is moving in that direction. Kind of we’re gonna eventually be–they’re gonna eventually pass a regulation that pushes even private businesses into this kind of requirements. This is kind of a visual graph or representation of kind of the levels. You’ve got Section 508 that we talked about, single A, double A, triple A, and more astringent is getting to the double A, and single A is–closely represents the Section 508 that’s currently law.
And you can see, I note on the bottom right, if you can read it, it’s kind of small, but it has one of those WCAG 2.0, 2.1, kind of if you’re wondering what those numbers mean, they kind of release versions every few years here, so you can kind of see when those are coming out and they’re expected a 2.2 coming out in 2021. Now, now we’re getting to it, so when we start planning for a–when do you start planning for accessibility? I believe the discussion needs to start at the beginning of any web design project.
In this discussion, you talk about, like, with your clients, you need to talk about branding colors, design strategy, layout, images, and even copy. All these factors play a role in the level of accessibility you wish to achieve. Building accessibility–build accessibility right into your workflow. Don’t–you know, get the stakeholders on board. Get them to understand why. It’s not just the laws, but the potential for you as in possibly opening up revenues for these–for organizations. And when I say revenue, it doesn’t always apply to, you know, businesses selling e-commerce.
Actually, I have non-profit clients that are backed, you know, by people with disabilities so they actually get more donations. So knowing that it can have a wider spread than just, you know, just the bottom line but it also has people who are advocates for their organizations. Yeah, accessibility should never just be an afterthought.
From my experience, if you do not build accessibility in your plan, it could possibly cause twice the work or money and time if you don’t build it in your strategy so, you know, as these laws come into law–into law in the future, you’re gonna have to go back in and change them but it just kind of makes it harder for everybody to kind of reprogram the brand to kind of tackle these projects again, especially after you’ve built large website projects.
Try to make it part of the–just try to make it part of the conversation every step of the way, you know. You know, if you’re talking about–it depends if you have a small team. If you have a small team of designers, developers, you know, it’s easy to kind of talk to the person who’s writing the copy and how should you plan for images and how should you plan
for page layout.
The bigger the team, the harder that gets but, you know, make it part of the conversation all the way.
All right, I’m gonna go over the main four principles. I think these are gone in over other meetings pretty extensively. I’ll try to keep it brief, but I wanna make sure that, you know, it kind of aligns what I’m gonna be talking about specifically, certain topics of the WCAG 2.1 principles. Perceivables, principle 1. Make sure you have text alternatives.
Provide text alternatives for any non-text content. Make it adaptable. A lot of web designers are know about responsiveness but also think about how that works when it’s responsive, when the framework is responsive. Time-based media, when it’s audio only or video only, provide captions or audio descriptions.
Distinguishable. We’ll be getting into this one more but–because it has to kind of more do with design. Make it easier for users to hear content including separating background and foreground. This in use includes color, audio control, contrast, resizing text and images and stuff like that.
Operables, principle 2. Keyboard accessibility. Make all function available by the keyboard. Seizures. Don’t make things flash in the screen. If you have, you know, things flashing, keep it at low because people are, you know, photosensitive. But you’ve got to have controls to kind of help stop that, and that’s enough time–giving him enough time, the user, to read the content. Stop and pause is kind of similar to that.
Navigable. Provide ways for user to navigate, find content and determine where they are.
Principle 3, understandable. Readable. Make the text content readable and understandable. Input assistance. Help users avoid content mistakes like examples like labels or instructions, error suggestions or error prevention. Predictable. Make web pages appear and operate in predictable ways, on focus, input, consistent navigation, consistent identification.
Compatible. Just make sure that the system is robust and compatible with a lot of user agents. User agents like web browsers or browser extensions, media players. Good news is that frameworks like Word Press and HTML 5 are compatible and are kind of built for future and continue in development.
But not all plugins are and other things like that, other developers you do not have control over will and, you know, frameworks like HTML 5 are great places to start. Okay, so, for this presentation we’re focusing on design and distinguishable is one of the most important principles in terms of design for accessibility. Visual elements like text, icons, input fields, and charts need to be easily perceivable.
On the most basic level, that means they need to be clearly stand out from the background. What is also important that they can be easily distinguished from similar elements around them. For example, linked, embedded in the text paragraph. The need to see things clearly is a shared among people who rely on their eyes but thechallenge are quite diverse. People with visual impairment might not be able to see certain colors. Their field of view might be blurred or narrow.
It’s also possible that the challenge is caused by the projection of light in the room or direct sunlight shining on the screen. But there’s real contrasts between a color is a key factor in making things perceivable.
But color contrast has its limitations. Creating robust visual differences between elements often require a more holistic approach. And when I’m talking about holistic approaches, it doesn’t only have to do with colors. It’s like things like arrangement, additional labeling, spacing, you know, like white space, content consistency.
Consistency is a big factor in accessibility and help make the content distinguishable–will all help make the content distinguishable on the website. All right, we’re gonna go into colors and contrasts for text. Providing sufficient contrast between foreground and background. For relevant luminance, the tone of color, whether it’s red, green, blue, yellow, is not a key factor. After all, adequate contrast is necessary for people who can’t perceive certain colors or who don’t see colors at all. This means visually distinct colors don’t automatically have a high contrast ration.
Sometimes, designers ask me what’s the best colors to use? It’s not always about the best colors; it’s about the contrast ratio of these colors. While visually non-impaired users might be able to perceive the red and green words on a blue background, for the image on the left, others will have a very hard time differentiating between the text and the background. The image on the right is how it might look to somebody who sees gray scale which, you can see, is very hard to distinguish, even for me as someone who can see.
Okay, continuing on this color contrast for text. To meet these standards, text should have a color contrast ratio of 4.5:1. This ensures that viewers cannot–who cannot see a full color spectrum are able to read the text. So this also depends on the size of the text, text color, background will determine an element if it meets these requirements. To understand kind of contrast ratio, 1:1 is the lowest contrast ratio. It means there’s no difference between the colors. 21:1 is kind of like the highest possible contrast ratio, kind of like white text on a black background.
While the highest contrast is generally good, higher is not always better actually, and research indicates moderate contrasts somewhere between the extremes is the best.
Just using black and white to reach a higher contrast is not good for all users.
This is sort of where the–this is sort of where the conversation needs to come in for branding for projects, I think, and can start with branding. I’ve had hard conversations with companies on their branding colors and what that means when translating to the web. Because if you diagnose a lot of websites out there for accessibility, you come to find out color contrast is probably one of the biggest hurdles to tackle, and the hardest to kind of for designers to keep things–they’re worried about being pretty and anesthetically pleasing but there’s a lot of techniques you can use to kind of get around that.
So moving on from text, we’re gonna do color contrast for user interface components. Version 2.1 of the Web Accessibility Guidelines minimal contrast is 3:1 contrast, adjacent colors for all UI components. Now we’re gonna start with a bad example.
In this one, the borders of input fields have insufficient contrast ratio, 1.5:1. Because of that, certain users may have a hard time finding input fields to enter. The background color of the “Send message” button also has a low contrast ratio, 1.5:1. This will make it harder for users to identify the button. Now we’ll continue on some more UI examples.
Form A versus Form B. Form B is kind of like A, on the right, is kind of saying, “Hey, this is anesthetically pleasing. This is what I like.” Form B, a little higher contrast, a lot more accessible, you know, borders, bolder text, bolder labeling text, things like that, kind of make that, make Form A much more accessible than Form B, and that’s kind of like a direct contrast on the same type of form. Now, this one is–there’s a lot of options here, 1 through 4, but we’re mostly gonna talk about 1 and 4 and how they contrast. The worst option is, obviously, number 1 in terms of accessibility.
The best option is number 4. You can see here a couple of things are happening in 4. There is the use of color, the use of icons and error messages to help the user understand what’s going on. Option 4 is a good example of not just using color to help to guide us. That’s good ’cause we’ve got a lot of other things to help use the–to help to guide the user on this. As the forms in general–as in forms in general, there can be a bigger conversation on best practice in making forms accessible.
I could have a whole presentation based on form accessibility. I think, right now, we’re just kind of going into kind of the visual aspects. As you can see on here, like, visual labeling, proper understanding–proper heading structure and sections, clear warning indicators like you see in option 4. But for this purpose, I just want you to know sometimes just how color is used when using it in user interface elements. Here’s a navigation example.
Navigation A uses color to show “Shop.” That’s–you select on “Shop.” But when you see in option B, it’s kind of what a colorblind person might see in navigation. You can’t tell the difference at all. They’d have no idea what the selection is. Now, option C, they bolded the–for “Shop” they bolded the text and they underlined it. And–which that allows for, when you see in option D, what a colorblind person, they can see, they can clearly see what is selected in this navigation example. Now, this is just–these are simple graphs.
These are just kind of to express a point. When showing kind of different types of information or displaying types of information, labels just don’t help. When someone’s colorblind, unable to tell the graph, what it is, apples, oranges, bananas, they would have a hard time distinguish between that. Option B kind of shows, hey, you can use lines or dots or some other type of indicator of what that information is conveying. You could get rid of the–but now they switch to another option, B.
You could just get rid of the legend altogether and just put the labels right on top.
And, well, long as it’s, you know, if you put the labels on top, make sure it kind of meets those requirements of the contrast ratio that we’re talking about, the 4.5:1, but, you know, you get the point with this. It kind of shows, hey, you can label this over the top and get rid of the legend altogether. And this is just kind of a extended version of what we just saw a second ago as well, just if you’re trying to identify colors or an image, you know, you can put 1, 2, 3, 4 over the top and identify with the legend on the right.
This also just helps further reinforce, you know, if someone has difficulty seeing. Include image and media alternatives in your design. For example, you might need visible links to transcript of audio, visible links to audio described versions of video, text along with icons and graphical buttons, captions and descriptions for tables or complex graphs.
Okay, so provide controls for content that starts automatically. That’s a big one. I always have battled this with clients. I have a lot of clients that wanna have automatic sliders or automatic videos playing when someone lands on–arrives on a landing page. And if you don’t have visible controls to stop those, it gets really kind of disorienting for certain users.
You can see in this one, there are links for–there are links for closed captioning. There’s links for speed control. There’s links, you know, there’s links for transcripts. This video just kind of allows more control for the user over this experience with the video. Now this is an ugly slider. Sliders are actually a big–for me, has been a big problem with achieving accessibility. People love sliders at the top of their websites or in the middle sometimes. And they all have their different challenges and, actually, there’s a lot of people who tackle them differently.
But when developing a slider or making a slider, putting one on your website, just keep some of these, you know, things in mind. You know, you wanna have controls. You wanna have navigation elements. You want ways for them to stop. You don’t want it to play automatically if you have that option with your slider.
So–and you want things to happen like if you have a–if you roll over with a mouse, just have it stop as well, so it’s not just the keyboard but other ways of interacting with this media. Needs to kind of have easy control.
Okay, now, image accessibility. A lot of people talked about this really great, you know, we have–other speakers already talked extensively about some of these. Like a presentation from Jerry Jones I think it was went on much more detail than I will compared on this–on this presentation. I’ll just kind of give you my take.
You can easily add, for example on this one, create an image that helps–help make your images more informative to the user is kind of the underlying tone of this. As you can see, the alt text I have on the screen, “Aerial view of Central Park in New York.”
You could easily just have the words “Central Park” there. You don’t even have to have–but “Central Park” doesn’t give any good indication of what this is about. Try to be relevant to the page content. So try to make the alt text sound supportive to the rest of the content on the site. If your site was about something about famous city parks, that alt text would work great.
But if it’s more about open spaces, you might be considering a different alt text to kind of drive your point home further on that. And for–and I got this question on linked. I would recommend alt text not be more than, like, 100 characters in length. If you need to go further, you can also add stuff to the description, but as far as, like, the alt text itself, you know, try to keep it around 100 characters in length. It’s also great for SEL if you do good alt text.
I’ll–two more examples on alt text, like this one. E-commerce websites, credit card–if you just use the word “credit card logos” as alt text, they don’t know which ones. A good alternative to this would be “Visa and Mastercard accepted.” So, you know, just a lot more descriptive what that means if they were using a screen reader. This doesn’t–this happens rarely in my case.
I don’t usually–I’m usually the graphic artist on the project. I don’t put a lot of–I’ve learned this from accessibility of not putting text over images. But if you do have a case of that, you know, type it out in the alt text. This example, “The quick brown fox jumps over the lazy dog.” If the text is on the image, you can put it in the alt text, is a good practice if you do it that way, but I just avoid it altogether, so.
Accessible navigation. Designers and developers should consider both site-wide and page navigation.
In general, provide multiple ways to reach any page on a site. Doing so allow users to choose whether–whatever way of finding pages and is easiest for them.
Users with low vision may find using search easier than navigating through a large menu. Users with cognitive impairments may prefer a table of contents or a site map over clicking through many pages. All right, in this–in a presentation earlier by Adam Berkowitz about building accessible navigation for search goes over accessible navigation in much more detail than I’ll go in this one today, but I would recommend to go back and listen to that presentation on how to make the navigation much more accessible.
I just wanna give some tips to consider on kind of my tips on it too as well. One of my first tips is using conventional locations for menus, such as across the top or along the left side. Don’t come with some, like, crazy hidden menus or along the right is also weird for people. So kind of like, that’s why I recommend the top or the left. Providing generous size for clickable areas, generally no smaller than 44 x 44 pix. You know, don’t make it real tiny, hard to hit, you know, hard to find, kind of locate these kind of links on the navigation.
Providing clear styles for hover or of the current states, also known as, like, focus. So when it’s on focus, you know where the cursor is or you know where when you tap in the keys to navigate the site, you know where you’re at. Ensuring that menus are keyboard operable and focus states are never hidden from users. Same what I said before but just kind of reassuring.
Don’t hide where they’re navigating. Avoid linking offsite when possible, unless properly marked by labels or aria-labels. Using navigation landmarks for screen readers. People go back and forth on this one. A lot of people have different ideas of how to do this kind of mark-up but I’ll go over a little bit of some examples here soon.
Keyboard accessibility. Keyboard accessibility is one of the most important aspects of website accessibility and many users with motor disabilities rely on a keyboard to navigate websites in place of a mouse. You know, I’d just encourage you to try to navigate any of your sites or if you–just with a keyboard. Just encourage you to try it, you know, use the tab key to go forward, use shift tab key to kind of go backwards, kind of backtrack. Keep in mind what we said earlier.
People have temporary disabilities that will have to use the keyboard or, you know, or later in life become disabled and they kind of need help using the keyboard instead of the mouse and they kind of prefer it.
All right, skip navigation and keyboard navigation. Skip links are internal pages links which aid navigation around the current page, rather than navigating to completely new pages. They are mainly used by screen readers for bypassing or “skipping” over repetitive page content. When I heard about ’em first, I had no idea where they were or how to even–how to figure them out so it took some time for me to kind of figure out how to use proper skip link navigation. Skip links can include, like, you know, like you see in the example, “skip over primary navigation,” but you can also have “skip to main content,” “skip to side bar,” “skip to footer.” I would keep it limited.
I wouldn’t do, like, 50 of ’em or something like that but I would keep it to kind of to the main section of the content you want people to have access to. Focus indicators. Can you tell–in this one, the question is can you tell where the element is in focus when they are using the keyboard? Does the element stop moving when it’s in focus? Elements include text links, buttons, forms, navigations, and sliders.
So all these elements you want to kind of have a way that, hey, this is what you’re focused on. Okay, we’re gonna go to the demonstration part of my project here. Let me see. Switch over to–I’m not picking on anybody when I’m demonstrating websites, I’m just trying to kind of show you, you know, how things work. Now, when you hit the tab key on–I’m using Unilever as kind of example. They’re a big company so we can kind of see. They say–the first thing you see is skip to content.
Now a user could hit enter on this and it’ll skip right down to the main part of the content. And as you continue that tab, it’s hard to tell but it went up to their Facebook, it went up to the very top of their–the main bar at the top. Then Twitter and then, you know, through all their social icons, and then it’s gonna–it moves to their logo which means their main website, you know, kind of home. About brands. You kind of see, as it’s indicating, you can see the square is moving along with me and I can choose that. Now, if I was consulting for Unilever, they have a great accessible website.
I think it’s a good example of it. But I also wish they had more skip links. I wish they had a way to kind of, you know, skip to the navigation instead of going through that top, very top bar. But that’s just, you know, that’s coming to my preference and you just need to have more users try the website out and kind of give you feedback to kind of make those corrections.
Now, landmark accessibility. What are website landmarks? They help screen readers identify sections of the website. It identifies areas like navigation, main content area side bars, search bar, footer, and copyright. On Unilever, they didn’t really have those–they didn’t have those sections identified and I can show you that in a minute as well. But I think that you use these landmarks or use aria-labels to help identify if HTML is falling short for you. It’s a good idea to have labels everywhere if possible but know that HTML 5 has a lot of this structure built in so, and not all screen readers use aria-label as its main source of information but it’s definitely still good to kind of consider adding these labels in.
Heading accessibility. Just think of each page as an outline for a paper, starting with H1 as the title at the top of the page, then continue to H2, H3, H4. You use headings to convey meaning and structure. When I’m working with copy writers I definitely, you know, I try to guide this as much as possible when they’re–when I’m working with them, try to help me kind of convey meaning to everything, including images. I bring them in the conversation across the board. All right, so, think about now they have the copy, and you’ve got the images going, think about the design and the page structure. This can help someone when navigating a website.
You can see here, you know, proper white space makes the relationship between content more apparent. Style headings to group content reduce clutter and make it easier to scan and understand. The example on the left just kind of has the main heading and a sub heading kind of grouped together. The image is kind of thrown in there. You don’t know what the association is with. The example on the right, the main heading and the image are grouped together and then the sub headings are kind of in their own area and the structure just makes a lot more sense.
Notes on reading. When reading on the screen, users benefit from having text at a lower reading level. While it’s not required for accessibility, it’s best to write it at a lower reading level as appropriate for your content. Doing so, benefits people with cognitive impairments, people who do not speak English as a first language and people who maybe are distracted while reading.
Some of the best practice for readability include writing at a high school grade level, where possible and appropriate; limit paragraphs to around 80 words if possible; avoid jargon and difficult language when possible. One of the tips I have is use a authoring tool such as Hemingway Editor. It’s a decent tool. You can get in there and kind of see what your readability is. I wouldn’t overthink this.
I know it really depends on the content of the website and, you know, if you have a very scientific website, you have to write at a certain level. But if you don’t need to make it overcomplicated, don’t.
Link and button accessibility. Okay, so we’re gonna–the example on the left shows no information. You see this on a lot of websites: “Learn more.” And in some cases, you can’t help it, like on a blog release. You “Learn more” a lot. But it doesn’t provide enough information for screen readers or people with visual impairments, kind of what that means.
Compared to the button on the right, it says, “See all events,” so you know directly where that’s gonna go. Even without context from a page here, you know that’s gonna go see all–see all the events. Also, the button on the left says “Learn more” in all caps. This is something designers never think about. We put–hey, we think that looks pretty, you know, make sure you put “Learn more” all caps.
I hedge against that. You, you know, do like it says, “See All Events,” you know, make the capital case like that. It helps differentiate the letters, it makes it a little easier to read. Okay, let’s see here. So, yeah, link the–continue on and the last thing, kind of, with button accessibility is, or link accessibility for this case. The left one said–has no information as well. “For information on device independence, click here.” “Click here,” you see a lot of people put that but click where is kind of what someone could ask. So a more meaningful version would “Read more about device independence.”
And they know that it’s about device independence is what they’re clicking on and they know where it’s gonna be going. That’s true with links going off the site. You know, you wanna address them, “Hey, this is leaving the site.” It’s kind of discombobulating to kind of just all of a sudden abruptly leave a site.
I’ve seen companies add links that go off their webpage in their main navigation and that’s even confusing for me, and I know what happened. So keep that in mind. Keep in mind the user when you’re developing links for a site. Now, tools to help check your ADA compliance. I can go to a couple of these. These are just what worked for me in my workflow. The best thing to do is actually have users use it, have people with disabilities use your website. That’s the best way to check for it.
But these are just kind of quick checks when I’m laying out a page or tackling a page, “Okay, what did I miss? What am I not thinking about?” And especially if I start adding more complicated things in there, like plugins or event things or things like that, I use these to kind of help me check or keep myself in check. Total ally, this is a live check so I broke these up in kind of live checkers that kind of float over the top of your screen and help you live check while you’re making edits. And there’s other ones you can actually submit a link.
This is another live check called Code Sniffer. This one’s really strenuous. It’s kind of confusing to use or it’s not confusing to use, it just, man, it really finds some crazy things on your site, so you’ll be, like, “Dang, I need to learn how to program better,” once you start using this Code Sniffer. And there’s also the W3C Validator. This is a well-known one but a lot of people have used it in the past. This is where you actually have to submit your kind of link to it. It checks it and spits back a report. Wave also has online and plus I think there’s a Chrome plugin. I put links here on this presentation.
You can go check those out.
These are great tools as well. Let’s actually demonstrate one of these while I’m here. Let’s do Total, Total Accessibility. Or I think they meant to say totally, but. Let’s refresh the page. We’ll go to Unilever one more time.
Let’s demonstrate this.
So the tool is a bookmark, so when you bookmark it, it’s at the top of your bookmarks, or wherever you hold it, and it puts a little icon in the bottom side of your screen. You click on it and you’re able to see, all right, check my heading structure. And this is a good example of a website so there’s not gonna find a lot of–ton of errors. But if it comes up on the right, you can see that they have a good heading structure. I can actually demonstrate what it looks like if you have a bad heading structure here in a second.
Contrasts. This is always kind of a doozy for a lot of websites but knowing that there are some warnings on contrasts like this one up here, the contrast insufficient for its–for this size. Yeah, you just kind of have to–it helps you diagnose like, okay, well, how can I correct this problem? Text links, labels, see, there’s not a lot of errors. When I click on “labels” and nothing comes up, that means they don’t–they have everything labeled. Image alt text. These are put as decorative.
I kind of–that’s from the programmer’s standpoint. I kind of wish that these images–wish these images had alt text in them. But you can mark them with a certain marking that says, hey, this is decorative element. But sometimes, designers do that to kind of get around things but I kind of wish these had alt text on them.
Landmarks. So this indicates landmarks saying there’s buttons up–these are buttons. What they didn’t do, what the–the bad thing that Unilever didn’t do was actually say, “Hey, this is navigation,” and “Hey, this is main content.” That’s something where they sort of are missing the mark, essentially, with landmarks. I’ll demonstrate the other here.
Code Sniffer. Code Sniffer, so this is where, when we talked earlier in the presentation, we talked about Section 508, WCAG 2, single A, double A, and triple A. Now, you can actually switch between the standards on this kind of code checker and, like, hey, Section 508, they only have one error. And you can view the report. And what this will do is, well, you can’t even see it. It’s off-screen, but it’s kind of pointing to this area, like, hey, this is where the problem is. It even spits out code saying, “Hey, check out this code,” and that’s what the error is. So you can switch now to double A, what we were talking about for most–there’s 150 warnings and 8 errors.
You don’t need to freak out about the warnings. The errors, you definitely need to check out. And you can–I have ’em organized by–and when I view the report, you can organize ’em by–you can see all of them and view the report or you can just see your errors and view the report. And this is just kind of a, like I said, this is a quick check. This is a good example.
This is a element, insufficient contrast. What it’s doing, it’s comparing the background to this white text and you kind of see this white image. It doesn’t really provide as much contrast. It says it’s 1.4:3, you know, it’s a small minimum contrast right here. So it’s saying we recommend 4.5:1. It actually has a 1:1. So, and even spits out a little code. So it’s kind of a work flow.
These are not a catch-all software. I recommend using a couple of different checkers as you’re working along to kind of see if either one can miss as each other ’cause they do not have–they do not catch everything.
All right, in summary, make accessibility part of your entire design process. Accessibility makes better site structure and easier for everyone to use. Better for search engines, SEO, and opens up the site to more users. For accessibility, kind of ending notes, it’s okay to start small.
Accessibility doesn’t happen, like, over–in one day or overnight. I think this was said earlier. Use your creativity things makes it accessible. Understand the guidelines but come up with your own ideas and to help solve some of these accessible problems and kind of share with the remaining–with the design community, developer community. Applying some concepts in your–apply some of these concepts you learn, kind of, in your next design project and, you know, if you do that, you kind of start setting the conversation forward and it kind of helps everybody. These are just some–my last page is here.
Just WordPress Plugins for accessibility: WP Accessibility, probably a very popular plugin. I’ve used it a couple of times. If you don’t know how to program skip links, this will help you with skip links. This also has a toggle for high contrast and large print and also helps you enforce alt text–alt tag attributes on your images. It has some accessibility stuff with Divi and Genesis Framework.
I didn’t talk about this but Genesis Framework was one of the first frameworks I use when it comes to accessibility. They really push–they, for a long time, they’ve been pushing the envelope for accessibility and I continue to support their programs and their software as far as kind of how their themes work and how their framework is, on the basis of accessibility. Thank you.
Megan: Thanks so much, Dylan. We do have a couple of questions from the audience. We have a few minutes here to get those wrapped up. So someone asked, “Is no black on white text a WCAG requirement?”
They said you were the second speaker that brought this up, and they were asking where they could find more about those requirements.
Dylan: Yeah, it’s not a–no, it’s not a requirement, is it asking–no, it’s not a requirement to have it that way. That’s–it’s just a recommendation. It’s kind of from research.
Like, it’s okay to have black and white, right, as contrast ratio ’cause that’s the highest contrast ratio. But it’s–there’s kind of a happy medium there, right? You don’t wanna overdo it because there’s actually certain types of users that are actually turned off by that high contrast. And it doesn’t work for them either.
So kind of–there’s kind of been some research on that. As far as the guidelines, they don’t have specific or exactly what color. They just want you to stay in the 4.5:1 as far as the WCAG AA. So kind of if you stick around that 4.5, 5, 6 and up, you’re good to go.
You don’t have to make it the extreme the other way. And plus, black on white’s kind of a harsh–you see on all black and white website, it’s pretty hard to look at.
Megan: So then, going off of that, would you suggest that sites provide contrast options for their users or should you rely on their operating system preferences and settings?
Dylan: Oh, that’s a good question.
Yeah, a little bit of both. I’ve had where, like, one of the plugins I talked about, WP Accessibility, they have like a toggling tool for high contrast, so it can actually switch your site into the high contrasts thing.
But, of course, people who have disability or use software to kind of interact with the web, they also have tools or preferences that are set for them. What you don’t want is to try to override those preferences for the users. I think you don’t wanna make it more difficult ’cause you’re not, you know, yeah, a good practice is try to make it the same for everybody, not try to figure out what you think this one user, how they want to use it. I don’t know if that kind of answers the question, but that, yeah, just be careful on some of those aspects.
Megan: So then for testing, for operating systems, would you recommend–is there a particular tool that you could simulate having those settings or do you recommend just testing multiple devices with accessibility settings turned on?
Dylan: Yeah, yeah, well, testing, testing, testing, right? Yeah, yeah, as much as you have access to. And also get out there in the community. You know, I’ve talked to several people on what they use, like, “Hey, what do you use?”
And that’s kind of the best gauge I can get. And you can look online the best you can but, honestly, finding users who have disabilities or who use the software and they have recommendations of the best things to use and that’s kind of where I start and then you kind of have to test on multiple platforms. I’m used to testing, as a developer or a designer, you’re used to testing on so many different things anyway, whether, you know, it’s different web browser, software, or what, but if you can find different ways to test, if you can multiple ways to test, it just helps you as a designer in general.
Megan: Great, that’s helpful. Our last question here is about a specific graphic that you showed where you had the various disabilities in different size circles, and they were asking what the different sizes were reflecting, if that was the amount of people with the different disability and do you have percentages that you could share?
Dylan: Oh no, I did run across that in research about that there are percentages. I did–I was gonna originally put that graphic in but I didn’t know–I was trying not to make it so confusing about what weight it is.
Yeah, there are certain types of users that are more and mostly probably motor skills, I think: people who need to use the keyboard is probably the most. And then, visually, is kind of the next group, but that visual group is a lot broader, I guess you could say.
I don’t know how to explain it. Like, there’s different types of visual disabilities. So I didn’t–I should have made–maybe that’s a good suggestion. I should make that image a little more kind of like, hey, this is the weight of this group. But, no, in that image there was not a–there was not a weight bearing.
Megan: Okay, well, I think that’s all we have. Thank you so much for presenting today, Dylan.
WP Accessibility Day has not assessed speaker-provided presentation resources for accessibility.