ABILITY

Hey everyone. Josh with Online ADA here, and in this video we’re covering article 4.1.3–Status Messages. This is a AA level requirement and I’ll jump into the description.

“In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.”

That’s the big one. This is saying that on your web pages you’ve implemented some way of conveying important information to people without them having to go to that information first. It’s–without receiving focus. So a big example for this one is form inputs. When we have validation errors or inputs that have some sort of error in them, it’s a perfect example of where you would wanna use this. When you go to submit the form your focus, or the user’s focus, is on the submit button, but the error exists up here–somewhere that they’ve already been. We don’t wanna have to wait for them to go all the way back through the form to get to that input to figure out that’s where the problem was. We wanna let them know right away where the problem was. So when they click that button, if you’re using the role of “status” or role of “alert,” then when the error appears on the page, it will be read aloud to them. The screen reader will pick up on it and read it out loud to them. And they don’t even have to move back up to the, uh, to the error. It’ll just say “hey, the first name field is required. Please go back and fill that in.” Or whatever.

This article says that you wanna make sure to use this whenever you have what’s called a “status message” on the web page and WCAG has determined what those are with two definitions, and I’ll read those now. “A message provides information to the user on the success or results of an action, on the waiting state of an application, on the progress of a process, or on the existence of errors.” And the second definition is, “The message is not delivered via a change of context,” meaning the web page hasn’t taken you some place new, the content hasn’t moved away in some dramatic way, then you could use a status message here.

Or, another good example is if you have something loading in the background, if you’re collecting results from some place to–to show the users some sort of form or some information they’ve already gathered and you have to go make a database call to get all that information–when the web page is loading, uh, there’s some sort of progress bar happening, or loading bar. Um, a blind user doesn’t know what’s happening. They can’t see that change or that context, so, using a status message, you could update them and let them know, “please wait while we gather your results,” or “loading,” or something like that. And you can do this with a couple of different ARIA attributes.

There’s ARIA Live, and you can do polite or assertive. Um, a really important message like a validation error, we’d probably use assertive, meaning it gets red before the other contents of the page. And polite means it’ll get read after whatever else has focus gets read. And then ARIA Atomic is another attribute you can use, and if you say “true” on ARIA atomic, it’ll tell the website that this region, whatever this container is, anything inside of here is going to be watched live so any new additions to text will be read out loud to the user over and over again.

Without ARIA Atomic, it’ll only get read the first time something changes inside that context, and then any new additions will get ignored. So ARIA Live equals assertive or polite, and ARIA Atomic equals true, you have yourself a live region where any additional text will get read out loud to the user. You can use that on any element or anywhere and you can have a fully live web page if you want to where all that content is getting read out loud to the user. All the changes are getting read out loud to the user.

And that’s what we’re talking about here in 4.1.3–Status Messages. So, that’s all there is. Thank you so much for joining me and I will see you in the next video.

Hey everyone. Josh here with Online ADA. In this video, we’re covering 4.1.2–Name, Role and Value. This is a level A requirement, and I’ll jump into the description.

“For all user interface components, including but not limited to: form elements, links, and components generated by scripts–the name and role can be programmatically determined. States, properties, and values that can be set by the user can be programmatically set and notification of changes to these items is available to user agents, including assistive technologies.”

There’s a note here. “Note one: this success criterion is primarily for web authors who developed or script their own user interface components, for example, Standard HTML controls already meet the success criterion when used according to specification.”

What this says is that whenever you’re using standard, native HTML–like a Nav element or a table or a button element–they’re gonna have their appropriate names, roles, and values already programmatically determined, assuming you’re using them the way they’re supposed to be used. If instead, however, you’re trying to use a div element and you’re trying to make it act like a button, then in that case, this applies. We’re gonna make sure that we have the correct name available to the assistive technology, –that’s an accessible name, by the way–the correct value can be determined for whatever it is, if it has contents inside of it, like a link if you have a div or a span that you’re trying to make work like a link, then you have all the relevant information for it and that includes the role of link. This is to ensure that the assistive technology knows exactly what it’s interacting with when it approaches that element.

So if you have, actually, a really good example of this would be when you have form inputs and you have labels that need to be associated to them or tied to them in some way. There’s two ways to approach a label and an input and making them work together correctly. You can either have the label be completely, separately removed from the input, but the input has an ID on it and the label has a four attribute that points to an ID–that would be one way. Or, you could have the label open tag and close tag and the input stuck inside of there–that would be another way. And what that does is when the user agent or the browser or assistive technology comes to an input, it knows that that label is associated and it will read the label for that input.

That’s just one example. There’s many, many, many examples and this is, again, just going to be specifically directed towards web authors who are creating their own interface controls.

This actually happens a lot and it’s not really feasible to make a website entirely built out of just native HTML, or at least native interface components. So you can’t just use inputs. Sometimes you need out of the box functionality–you gotta make that yourself in those cases. You need to make sure that you’re providing the correct role, states and properties.

If you have a button that opens a menu, for instance, then you’re gonna wanna use ARIA dash “pressed” equals “true,” if it’s been clicked on. If you have a tab list, you have the correct role of “tab list” and then all the elements that open the various stages of the content are going to have role of “tab” or role of “tab content” and you’re going to have ARIA controls and all those different attributes, which can be found on the website.

And the W3.org website has a lot of examples and tutorials on how to correctly, programmatically associate these things. But it’s important that they’re all there and that they’re implemented correctly so that we know what we’re interacting with when we reach it. This is to help everyone with every kind of disability who needs the assistance of assistive technology, okay?

Thank you so much for joining me. That’s all there is in this one and I’ll see you in the next video

Hey everyone. Josh here with Online ADA. In this video, we’re covering 4.1.1–Parsing. This is a level A requirement and I’ll jump into the description.

“In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except for the specific–uh, specifications allow these features. Note one: start and end tags that are missing a critical character in their formations, such as a closing angle bracket or a ‘mismatched attribute value,’ are not complete.”

This article is basically saying you need to know your basic fundamental HTML. This is probably more in line for developers who are building these accessibility tools, not so much for site owners who are delegating that information or that responsibility to someone else. But it’s important to understand the HTML.

The HTML is the foundation of accessibility for digital websites. You have assistive technology of all kinds–hardware, software. You know, synthetic speech, voice overs. You’ve got Braille machines that are gonna interpret the content on the page and give the user relevant input or feedback on their device. All these things require that the HTML is marked up properly because if it’s not, then the assistive technology has no idea what’s really going on. The website is, in effect, broken.

Having multiple IDs means that the previous IDs are probably missed or ignored because only the last ID is gonna be used. Another example–you cannot have interactive elements within a button or a role button element, so you can’t have a button inside of a button. It’s stuff like that. This article is saying make sure that your HTML is clean and good and functioning. That will be giving anyone using assistive technology the best chance that they have to use your site effectively, okay?

That’s all there is for this article. Make sure you know your HTML or make sure you’re hiring someone who does and you’ll be golden for this one. Thank you so much for joining me and I’ll see you in the next one.

Hey everyone. Josh here with Online ADA, and in this video we’re covering article 3.3.4– Error Prevention: Legal, Financial Data. This is a AA level requirement, and I’ll jump into the description.

“For web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user controllable data in data storage systems, or that submit user test responses, at least one of the following is true: Reversible–submissions are reversible. Or, Checked–data entered by the user is checked for input errors and the user is provided an opportunity to correct them. Or, Confirmed–a mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.”

This is the kind of thing that you see a lot when you’re doing online taxes or if you’re doing anything online with a bank that requires multiple forms to be submitted that convey information about yourself. I like the tax, uh example, because that’s one that I’m familiar with personally. You see that online, you’ll see, uh–enter in all of your personal information, all your dependent information, all–your street address, enter in basically all sorts of information about yourself when submitting your taxes. Imagine if we didn’t have any way to correct any mistakes that we’ve made. And what you’ll see a lot of times with these is after you’ve entered a big chunk of data, at the very end of that section you’ll see a review page where you’ll have all that information that you’ve entered with options to edit and make corrections. That’s exactly what this is talking about. That’s a great example of this. You’ve entered a bunch of information and at the end you can review it and confirm–or correct those mistakes if you’ve made any.

This success criterion aims to help people with all sorts of disabilities, all over the spectrum, there. Because people with disabilities, often times when it comes to digital interactions and using these web pages, they’re more prone to making mistakes. So this allows them opportunities to go back and correct those mistakes and it evens it out for them.

Another really good example is a checkout system. We’re all familiar with checkout systems. I’m sure if you’ve ever been on Amazon.com or any other website where you can purchase items, you’ll typically have some sort of cart that you can review. You’ll have multiple pages where you can apply coupons and all sorts of different things. You can modify the contents of your cart and then at some point you’ll be offered a checkout, and you’ll have to enter your payment information. Through that whole process, if you have a chance to review your cart then you are reviewing that– that, uh, this criterion–you’re reviewing your data that you’ve submitted. So you have a chance to correct it or reverse it by, maybe, removing the item from the cart.

That’s really what this success criterion is doing. It’s–it’s basically giving people an opportunity to go back, to make, uh–to change their mind if they’ve made some sort of mistake Okay?

So that’s really all there is for this one. Thank you so much for joining me and we’ll see you on the next one.

Hi everyone. Josh here with Online ADA. In this video, we’re covering article 3.3.3–Error Suggestion. This is a AA level requirement, and I’ll jump into the description.

“If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content.”

This is a very important guideline for a number of reasons. Some of those are people with learning disabilities or cognitive disabilities can more easily fill out forms and they don’t have to guess at what the contents need to be or what the format needs to be for them. People who are blind or have vision impairment don’t have to guess at what the error is, and they can more easily identify the nature of the input error. And then people with motion impairment can reduce the number of times that they have to re-enter the input. Uh, the core of this article is basically saying that we want to identify what the error is, based on the last criterion, and then not just saying, “hey, you’ve got an error on this form somewhere–please review the form,” you wanna suggest what’s wrong.

For instance, if a form input is required, then you can say “the first name field requires an input” or “please enter something in the month input.” The documentation itself actually has a really good example that I’ll read through here for you as well. Um, this is suggestions from a limited set of values. An input field requires that a “month name” can be entered. If the user enters “12,” suggestions for correction may include a list of acceptable values, e.g.: “Choose one of: January, February, March, and so on.” A description of the set of values, e.g.: “Please provide a name of the month.” Or, a conversion of the input data interpreted as a different month format, as in– “Did you mean December?”

Those are all great suggestions for how we could fix this input, because something is wrong. We wanna just get the user to success as quickly as possible. So, using something like this technique, where we’re either interpreting what they’ve entered and trying to come up with a different–a better solution for them based on that input, or we expect a very specific type of input. We put those expectations out there in the input. Uh, “Did you mean December?” or “Choose from one of these: January, February, December…” So on and so forth. These are great examples. We’re just informing the user that there’s something wrong, and here’s what we think is the problem–give that a try.

Um, that’s all there is. This is to help those folks with learning and cognitive disabilities, motion impairment, and low vision. We’re–we’re helping them get to where they wanna be and helping them achieve success when using our sites as quickly as possible. Helping out in any way we can.

So, thanks for joining me in this article and we’ll see you in the next one.

Hey everyone. Josh here with Online ADA, and in this video we’re covering article 3.3.2–Labels or Instructions. This is a single level A requirement, and I’ll jump into the description.

“Labels or instructions are provided when content requires user input.” It’s real easy. This article overlaps with a few other articles, in fact, such as 1.3.1–Info and Relationships, and 4.1.2, which is making sure that everything is programmatically tied together. But 3.3.2 is actually very specific. It simply says that if there are extra instructions or we have some element on the page that the user can interact with, then we have some sort of label for it, especially when it’s referring to inputs.

This is actually most of the time–when we’re talking about this particular article–if we have a select drop down box, a check box, we have a text area, we have a newsletter sign up… This isn’t so much for buttons or links as it is for those inputs in a form. This simply says that we need some sort of visual, textual representation of what this input does, and if there are extra information, then we need to explain that as well using these labels or instructions.

So, essentially what you will most commonly see is in an input field. You’ll have, for instance, the input field requires a username or let’s say an email. That’s a really easy one. Then right above it it’ll say “Email” in big, bold text, right? That’s just a really standard way of providing a label. This doesn’t talk about how your markup would look or how you’re associating the two. In fact, to meet this criterion it literally just has to be on the page nearby, in proximity. In addition to the label, if we have extra information that we need to relay to the user–like a specific format, for instance, on a form field–then that text is also present somewhere nearby as well, most likely right underneath the label itself.

And that’s all there is for this. We have a textual representation of what the input is or what is required from the user and then extra information is there as well.

That’s the instructions part of that. So thank you very much for joining me in this article and I’ll see you in the next.

Hey everyone. Josh here with Online ADA, and in this video we’re covering Article 3.3.1–Error Identification. This is a level A requirement and I’ll jump into the description.

“If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.” This is because relying on audio or visual cues alone is not enough to let the user know where the error has happened. When we use text instead–or in addition to–visual or audio cues, the users can more easily identify where the problem is, especially if it’s on some sort of form. And forms a lot of different behaviors.

For instance, sometimes validation errors can happen as soon as you click the button. Other times they happen after the page refreshes. And if we don’t provide multiple ways for them to identify the error, it can be really confusing and the assistive technology may not indicate to them right away where the problem is, relying instead on the user going all the way back through the form to find the individual fields. If the user isn’t aware that there’s some sort of input error before they attempt to submit the form, they may find that–or they may think that the form is not behaving correctly or that the form is broken, instead, not realizing that they need to in fact to go back to the form input fields, specifically, to find that information.

So there are a couple of best practices here. Number one–a good strategy is to make sure that your validation errors on your forms are firing either on the click event of the form or like right after the form click event so that you’re not actually submitting the form, you’re showing the errors ahead of time. This is because if you refresh the page and then show the form again with its errors, the screen reader, the assistive technology, may read that the page did, in fact, submit correctly, and we’re on a new page and start reading from the top again. The user, meanwhile, is unaware that there was a problem with the form. So we wanna make sure that we get these errors to the users as quickly as possible.

Another good practice is to put the error in the title of the page so that when the screen reader reloads–this is, for instance, if you’re refreshing the page– you would have it in the title so that when the title is read, it would indicate that that page did not in fact, submit correctly and that there are errors that require attention.

In addition, we want to try using ARIA attributes as well on our forms to indicate that there is something that needs to happen with this form, specifically, when the user approaches it the first time. We wanna get these warnings to our users as soon as possible, so adding an attribute like Aria required equals “true” is going to let the assistive technology know, and thus the user know, that this field is required. You can also put things like (Required) after the label of the form input and this will just further give them information.

Another really good technique is to use the role of alert on your form itself so that when you submit the form and validation errors are found if, you’re inserting text–which I’ve seen a lot in my audits and I think it’s really good idea–you insert text underneath the input or above or beside or some image or cue, then when that image, rather when that text gets added to the form the role of alerts will actually read it out loud to the user. That is not mandatory for this article, but it is a good idea because it tells the user something’s wrong without them even having to move around the form again. Just reads it right out loud to them.

So, the big take away from this article is to make sure that we’re not just using audio or visual cues–we need text in addition. it’s a great idea, in fact, to use both together. That when we submit the form or when we click the submit button, we are indicating to the user what things are wrong.

It’s also important to note that if we have a number or a range field, that if the user enters a number that’s too high and we have some sort of logic that automatically sets the number back down–let’s say we have a range of one to ten in a number box and they enter fifty and the automatic filter that we have in place brings it down to ten, which would be the maximum range for that box, we would need an indication there as well of what the user did wrong. There’s an error identification that the user is aware of what’s happening and they don’t just blissfully move on thinking that their fifty took place.

So, with that said, that’s really all there is to this article. Thank you so much for joining me and I’ll see you in the next one.

Hey everybody. Josh here with Online ADA. In this video, we’re covering 3.2.4–Consistent Identification, which is a level AA requirement.

I’ll read the description. It says, “components that have the same functionality within a set of web pages are identified consistently.” So, this is specifically pertaining to elements that are repeated, okay, throughout your site.

Um, if you have multiple icons on one page and they serve different functions–this isn’t referring to that. It’s specifically, uh, if you have, for instance, maybe a search input in your footer, something that is repeated on every page, and a button for submitting the search. On one page maybe it says “submit,” on another page it says “search,” or another page that says “find,” or something. That’s not consistent. That would be breaking this accessibility guideline. We wanna make sure that the identification for that icon is going to be consistent and the same because it serves the same purpose.
Similarly, if you have check marks or check boxes, uh, across one form and then on another page, you have another form that has check boxes–if they’re serving the same purpose, then they are labeled consistently. If they, however, serve different purposes, for instance, if in one form the checkbox indicates that something is approved and then on the other form, the checkbox indicates that something is included, like a file or something, then that would be different functionality, and exempt from this rule because it is not, uh–it doesn’t need to be consistent. They’re not the same functionality.
Another really good example of this is if you have pagination on your site. Um, on blog articles, especially, this comes in handy, you’ll see, um, a lot of times a blog article with the title, the featured image, and the content, maybe like the author stuff at the bottom. At the top, you’ll have, “go to previous article,” and “go to next article,” right? So if those change from page to page, that would be an example of inconsistent labeling. If it said, “go to next page” or just said “next” and on the next page it said “go to something else,” that would be inconsistent because one time it said “next,” one time it said “go to blank.”

If, however, you’re viewing them all on the same page and you have pagination with, uh, like a previous arrow and a forward and then you’ve got the different buttons down, uh, arrayed in between those arrows–if the next button said–if you’re on page five and the next button says “go to page six,” then you go to page six and then that button says “go to page seven,” that is consistent labeling because even though they’re not identical–keyword–similar, they are consistent. You don’t want them to be identical, necessarily. They don’t have to be. They need to be consistent. They need to reflect the same functionality in each place they’re identified.

If you have a “download” button, uh, some place on your site or even like a “print” button and the icon is like a cloud with a down arrow or something–I see that a lot– you would have the button, “download or print X.” So in this case, it’s for printing this article. Go to a new, uh, new page, now it’s for printing THIS article. “Print / the name of the article” is consistent, even though the article name changes each time, it still is labeled, firstly, with “print.” You don’t have a bunch of other extra, extraneous text, um–that’s consistency. Okay? Hopefully that’s clear.

Thank you for joining me in this video and I’ll see you in the next video.

Hey everybody. Josh here with Online ADA. In this video, we’re covering 3.2.3–Consistent Navigation.

This is a AA level requirement and I’ll jump into the description. “Navigational mechanisms that are repeated on multiple web pages within a set of web pages occur in the same relative order each time they are repeated, unless a change is an issue by the user.”

Navigation on your page can mean a couple of different things. Um, your main primary navigation at the top of the, uh, website. Uh, let’s say on the homepage, or really all pages, uh, if you have the ordered list of links of all the primary pages on your site in a particular order. That would be one example. Um, having a “skip to main” link that is always the first element on the page. That’s an example. Having a search bar, maybe in the footer, that’s always in the footer in the same place.
That’s what this article is talking about– is consistency. We’re saying as soon as you go to a new page, you expect that–if on the last page–the first link that you visited was the “skip to main” link, on this new page, the first link will be the “skip to main” link. If you can reliably go to the footer and find a search, uh, menu or a search input on the page you just visited, then on the next page you can do the same thing, and all subsequent pages. And the same goes for the menu at the top–the navigation menu. Uh, or on the side, or however you presented it. But most commonly I see them across the top horizontally, so I just use that as an example. But it can be in any order or any way that you present it.

We’re talking about consistency of the order– the relative order.

So if you have a menu that has, uh, five links in it and on the homepage they’re listed a certain way, when you follow those links individually, you expect that every page that you visit, that order is gonna remain the same. That’s this article. Consistency.

There are users out there who have intellectual and cognitive disabilities, low vision, or even blindness. Uh, some folks use, um, the magnifier tools in the browser or some sort of third party software and they’re relying on spatial awareness. They oftentimes go to the edges of the screen as a starting point, and then they can go over from some place so that they can reliably get to the same content over and over again. And if we’re changing up the order of where these icons and elements are located, then they’re gonna have difficulty navigating. It can be disorienting and it can be difficult to, uh, consistently navigate through the site. We wanna avoid that and, again, this is a AA level requirement. So, uh, something to be considering on all of our sites. We should have these things, um, consistently located and in their same order each time we visit a new page. Okay?

That’s all there is for this article. Thanks for joining me and I’ll see you in the next one.

Hey everybody. Josh here with Online ADA, and in this video we’re covering 3.2.2 on Input. This is a single level, A requirement and the description reads “changing the setting of any user interface component does not automatically cause a change of context, unless the user has been advised of the behavior before using the component.”

Uh, that’s a big one. Basically, what this article is trying to say is that when you are interacting, as a user, when you’re interacting with content on a page, you want it to be predictable. You wanna know what’s gonna happen and not have to think about whether you’re being redirected somewhere, your focus is changing, or what have you. The exception, of course, being if you are describing–before interacting with that content– what’s gonna happen.

So, let me give you some examples. When I do audits for sites, I’m–basically, I come across a lot of these situations where folks like to input a select element, and what they do is when you make a choice on the select drop down they’ll initiate something–some action–whether it takes you to a new page, it loads new content, something like that.

That would be an example of on input. You have made a choice in the drop down, but what if you made the wrong choice? What if you are just exploring what the different choices there are by simply using the down arrow? Well, every time you do that you’re making a choice, in this context. So that would be a bad idea. A way around that would be to instead provide a button next to the select element and once you’ve made your choice, then you hit submit. That would be the way around that. That would be predictable, okay?

Another way to fail this criteria would be to have a form that’s submitted, uh, just once you had finished interacting with all the components. Let’s say you have five form fields that need to be filled out and as soon as you’ve filled out the requirement for the last one and you’ve moved past it or even just typing in, it submitted the form for you. That would be pretty crazy, right? It wouldn’t be predictable. I wouldn’t know that that was gonna happen unless you specifically said that it wouldn’t. Even then, that’s probably tricky. You wouldn’t really want that because you want a lot to allow people to backtrack and undo errors that they’ve made. So it’s important to make sure that your site is predictable.

I do feel that it’s important to identify what a change of context might be. In this case, and in many cases, a change of context are something like a new tab or a new window or just being redirected to a new URL, effectively removing the option that initiated the change. If you are using a radio button or radio group and you have three options, and when you choose one it just opens a new page, then you would have to go back and find that element again. That’s a change of context. If your content on the page, if you have, for instance, a one page checkout, for instance, you could have a situation where you’re making a choice of, um, maybe quantity or you’re trying to enter a coupon or something, and as soon as you have typed something in or you’ve made a selection it changes to the next page. It didn’t change to a new URL–it just loaded new content, and your option has been taken away. What if you made a mistake and you wanted to undo that? That’s a change of context.

A situation where it IS okay to do something like this is like a tab list. If your radio buttons, instead, change what content is presented below the radio buttons as you make your choices across them, new content appears–that’s changing just part of your context. You haven’t removed their ability to, uh, make a new choice, and that is okay in this instance. Another common situation I see that’s worth noting is on form fields that require a phone number. Maybe they’ve broken up the phone Into three separate boxes, right? And so the first one is the area code and then you’ve got your different three-digit, four-digit situation. Well, if you are allowing a user to tab into the first, the area code box, and then as soon as they type in three numbers it just moves to the next box–that is a change of context. You’re no longer in the same element, right? You’ve been you–your option to change what you’ve just typed in has been removed from you. You have to go find that. And imagine how difficult that would be for a non-visual user who, now, is in a different input box and they don’t realize it, um, assumingly.

So, in this case, if you describe ahead of time that that is what the behavior is, then it’s acceptable, according to this criteria. So we just wanna be mindful that our interactions are predictable and that we’re not disorienting our users by providing, um, non-standard interactions with our interactable elements. Okay?

Thanks for joining me and I’ll see you in the next video.