DEV Community: TabathaSlatton

Accessibility 101

TabathaSlatton — Tue, 30 Mar 2021 16:54:45 +0000

Impairments Basics

Impairments can be visual, auditory, mobile, cognitive, or speech based. They can also be situational, temporary, or permanent. Not being able to see your screen well outside during a sunny day is an example of a situational visual impairment, having a concussion is an example of a temporary cognitive impairment, and having an absent limb could be an example of a permanent mobile impairment.

When we build web content, we need to keep impairments in mind. Building with impairments in mind will help all of our users.

When thinking about how to best help our users, we need to remember:

Some users navigate using a keyboard only, having all interactive content accessible by keyboard is essential (note, all interactive content. Adding things like headings to the tab order can be confusing and lead to trouble with finding content that is needed…more on this later)

Anything that is sound based should have a visual as well

Don’t over design. Optionally, have a minimal design option for users with cognitive impairments to reduce distraction and cognitive load

WCAG Basics

WCAG provides a benchmark for accessible content. It is build around four principles of what we content should be for users.

Web content should be:

Perceivable - making sure users can receive content regardless of impairments
Operable - making sure users can operate ui components and navigate content
Understandable - making sure all user understand the interface and it is consistent enough to avoid confusion
Robust - making sure it is robust enough to be consumed by a wide variety of users and it works with assistive technology.

This is commonly referred to as POUR.

Following WCAG guidelines will get your content most of the way when it comes to accessibility. Just remember, we’re building content for USERS, not to fill out a checklist. Verify the tab order (more on this soon) and that your content is working with a screen reader (more on this soon) to make sure your page is truly accessible. User experience is much more important than checking off a box.

Focus/Tab Order

Users should be able to access all interactive elements from their keyboard, specifically from clicking tab. This is the first thing to check on a page you’re assessing for accessibility.

The tab order should be logical, from top right to bottom left. If CSS has moved an element to a different part of the page and that’s affecting the tab order, the item needs to be moved in the HTML. Tab order is based on the DOM.

Native HTML Elements have focus build into them (you will automatically be able to tab to input and button elements, for example), but rarely (it should be pretty rare) you will need to create a custom HTML element.

You can add/alter focus behavior with the attribute tabindex:

tabindex=”-1”
- Element will not be in the natural tab order
- Element can be programmatically focused with focus() method
- This is very useful for content that is offscreen and appears on screen after a user event (such as a dashboard being offscreen until a user clicks a hamburger menu)
tabindex=”0”
- Element will be in the natural tab order
- Element can be programmatically focused with focus() method
tabindex=”3” (or anything greater than 0)
- This is an ANTI-PATTERN, do not do this. It can jumble the tab order and is very confusing to screen readers
- Element will be in the natural tab order
- Element will jump to the front of the tab order
- If there are multiple, the order will start at the smallest above zero and work it’s way up

When to implement focus behavior

Focus behavior should only be added to input controls (for example, buttons and other interactive elements). Just a reminder: if you can, it is always better to use native HTML elements. They provide a ton of behind the scenes functionality that would take a lot of extra work and code to implement correctly with a custom element.

Normally, focus behavior should not be added to anything that is not an element that users interact with. For example, it shouldn’t be added to headings or paragraphs. An exception to this is when you’re wanting to manage focus. A great example of this would be having a bar on the top where users can click a button (already has focus in the tab order with native HTML element button) that will take them to a heading. To this heading, you can provide an attribute of tabindex=”-1” and call the focus() method after the user has clicked on the button.

No hidden focus elements

There shouldn’t be any hidden focus elements on the page. An easy way to test this is to tab through your page. As elements are focused, they will have a focus ring (you can customize the behavior/ styling of the focus ring, more on this later) and should be visible on the page. If your focus ring disappears and you can’t find where the element is, you can check what is active with document.activeElement in the console. This will give you a reference to the element. If the element isn’t visual on the page, it needs to be removed from the tab order or made visible.

No keyboard trap

Users should not get to a place where they cannot tab out of. An exception to this is a temporary keyboard trap on things like modals to make sure they cannot tab outside before the task is complete.

Implementing a modal keyboard trap: an example
In HTML have a modal with some task (such as a confirmation or shopping cart modal). It would have similar class/ids as shown in the javaScript example.

JS:

// initialize variable to store the element users focused on before the modal popped up
let focusedElementBeforeModal;

// select the modal, model overlay, and modal toggle from the dom
const modal = document.querySelector('.modal');
const modalOverlay = document.querySelector('.modal-overlay');
const modalToggle = document.querySelector('.modal-toggle');

// when the modal toggle is clicked, we'll open the modal
modalToggle.addEventListener('click', openModal);

function openModal() {
  // save current focus
  focusedElementBeforeModal = document.activeElement;

  // add event listeners to trap the tab key within the modal and close the modal if the overlay is clicked
  modal.addEventListener('keydown', trapTabKey);
  modalOverlay.addEventListener('click', closeModal);

  // add event listeners too close the modal for specific items in your modal
  const resumeShoppingBtn = modal.querySelector('#resumeShopping');
  resumeShoppingBtn.addEventListener('click', closeModal);

  // find all focusable elements in your modal
  const focusableElementsString = 'a[href], area[href], input:not([disabled]), select:not([disabled]), 
  textarea:not([disabled]), button:not([disabled]), iframe, object, embed, [tabindex="0"], [contenteditable]';
  let focusableElements = modal.querySelectorAll(focusableElementsString);
  focusableElements = Array.prototype.slice.call(focusableElements);

  // store first and last focusable elements to lock within
  const firstTabStop = focusableElements[0];
  const lastTabStop = focusableElements[focusableElements.length - 1];

  // display modal and overlay
  modal.style.display = 'block';
  modalOverlay.style.display = 'block';

  // focus first child element
  firstTabStop.focus();

  function trapTabKey(e) {
    // check if the key pressed was tab
    if (e.keyCode === 9) {
      // check if it was shift + tab
      if (e.shiftKey) {
        // if we were already on the first, mode to last
        if (document.activeElement === firstTabStop) {
          e.preventDefault();
          lastTabStop.focus();
        }
      // else if they just hit tab 
      } else {
        // if we were already on the last element, we're going to move back to the
        // first, completing the trap
        if (document.activeElement === lastTabStop) {
          e.preventDefault();
          firstTabStop.focus();
        }
      }
    }
    // if the key they hit was esc instead of tab, we'll close the modal
    if (e.keyCode === 27) {
      closeModal();
    }
  }
}

function closeModal() {
  modal.style.display = 'none';
  modalOverlay.style.display = 'none';
  focusedElementBeforeModal.focus();
}

Using skip links to save navigation

Skip links should be used so users can tab quickly to the main content in the page. This allows for quicker navigation for keyboard users and users with assertive technology.

Example code (This is just an example to start off with, actual implementation will look different):

HTML:

<!-- the a tag is before nav and other dom items -->
<a href="#maincontent” class=”skip-link”>Skip to main content</a>

<nav>
  <!-- nav items -->
</nav>

<main id=”maincontent” tabindex=”-1”>
  <!-- main content in the page -->
</main>

*note that the href and the id in the main are the same.
CSS:

/* make sure the color stands out against the page 
and the link is placed outside of the page to start */
.skip-link {
  position: absolute;
  top: -40px;
  left: 0;
  background: #BF1722;
  color: white;
  padding: 8px;
  z-index: 100;
}

/* when focus is on the link, it will move into view */
.skip-link:focus {
  top: 0;
}

This is a great article on skip links and the website itself is a great example of both skip links and tab order.

Web AIM skip nav article

Semantics

One major goal with web content is to enable users to interact with your page with as little training as possible. We use affordances to build meaning.

Graphical Affordances

Users should be able to look at a design to determine what it does. For example, buttons for clicking and sliders for scrolling should generally look like what users expect them to look like. If a user cannot figure out that your button is a button, it is not providing enough graphical affordance. Other examples of graphical ui affordances include items that mimic real life things users might see, such as a checkbox. They’ve likely seen them on ballets or on other forms they might have filled out in different settings.

Affordances for non sighted users

Information should be expressed in a way that it can be accessed by assistive technology.

Screen Readers and other assistive technology will use the accessibility tree to create a user interface. This accessibility tree comes from the browser. The browser essentially takes the DOM tree and modifies it in a way that is useful to the assistive technology. It takes out all of the style and visual only elements, presenting users with only the content they need.

The screen reader will announce an element’s:

Name: name label, title, and text alternative all relate to the name
Role: what kind of element it is (ex: button, checkbox, edit text)
Value: what users have input
State (ex: checked or unchecked for checkboxes, selected, collapsed, etc.)

Labeling Content

The following traits need to be implemented in HTML:

All input elements need to have a label (so their name is discoverable)
- Visible labels are provided both for sighted users and non sighted users
- We can use a label for element or wrap the input in a label, either works
- If no visible label is needed, a text alternative should be used
Images are required to have an alt attribute.
- If the image is simply decorative, the alt tag can be empty (alt=””)
- Otherwise, the alt text must be descriptive.
- With no alt, screen readers will have bizarre behavior such as reading the file name.

Screen Reader Tips

When you’ve finished making sure your webpage’s tab order seems correct, try out a screen reader next! Mac’s have a built in Screen Reader called “VoiceOver” under the accessibility section. There is a training you can do with it that will guide you through the very basics of using it, I highly recommend checking it out! There are screen readers available on all systems so if you are working on a different one, a quick google search should provide you with some great resources on those.

Screen readers read directly from the DOM order, not the visual order. Fixing the tab order should have helped this, but there may need to be fine tuning for elements that were not focusable.

Link text needs to be descriptive. Users should know just by looking at the link what they will be getting. Screen readers have the ability to jump to all of the links or quickly navigate content so we need to make sure every link is clear and descriptive.

Page Landmarks:

Landmarks are a big deal with screen readers and aid in quick navigation. They help users find the semantics of the region of a page.

Landmarks that can and/or should be included:

main
- There should typically be only one main element that contains the main content of a page
header
footer
nav
article
- Self contained sections of content such as a blog post, news article, etc.
section
- A generic section of an application
- Usually, we put a heading inside to add details
aside
- Content that is tangentially related to the content around it such as a “fun facts” section

ARIA

As W3 states on their page, bad ARIA is worse than no ARIA. Do not use ARIA if native HTML will fit your user’s needs. Native elements give you semantics, keyboard support, and focus essentially for free where building the same thing in ARIA will take a lot of code and a lot of time.

ARIA or WAI-ARIA stands for Web Accessibility Initiative Accessible Rich Internet Applications. It allows you to specify attributes on elements and modify how that element is translated into the accessibility tree. In fact, all aria changes is the accessibility tree.

ARIA does not:

Modify the element’s appearance
Modify the element’s behavior
Add focusability
Add keyboard event handling

ARIA Roles

Roles in accessibility explain particular UI patterns. Roles such as “checkbox” give users of screen readers an idea of how they should interact with this piece of content. Reminder: HTML gives roles for free, when in doubt, stick to HTML.

See W3 for a list of ARIA roles and what is required to implement them should you need to build a custom element.

Labeling with ARIA

ARIA-label can be used to add a label to anything that has a visual representation of what a UI element is where a description might be needed for screen readers. For example, a hamburger menu might have an aria-label=”menu”.

ARIA-labelledby allows us to label elements that cannot be labelled with a label tag (such as a generic div).

<div aria-labelledby=”label1”</div><span id=”label1”>I'm a label</span>

ARIA-labelled by does not give you the clickablity label gives and overrides label as well as aria-label.

ARIA-live

Should there be something you need to alert your screen reader users about, ARIA live provides good options.

aria-live=”assertive”
- alert happens immediately, interrupting whatever the user was doing
aria-live=”off”
- you do not have to declare this, this is the default state, no alerts will happen
aria-live=”polite”
- alerts user after anything in progress is done

There are three attributes which work with aria-live to fine tune what is communicated to the user

Aria-atomic:
- Indicates whether the entire region should be considered as a whole when communicating updates
Aria-relevant:
- Indicates what types of changes should be presented
- Additions: any element being added to the live region is significant
- Removals: removing text or descendant
- Text: text content being added/changed
- All: everything
Aria-busy:
- Don’t alert in this time, such as loading

Style

For AA, a minimum contrast of 4.5:1 is required for all text and images. Large text (18 point or 14 point bold) can be lowered to a minimum of 3:1

For AAA, the minimums are 7:1 overall and 4.5:1 for large text.

We should expect an average of 1 per every 20 users to have some sort of color vision deficiency, with that in mind, information needs to be conveyed in more ways than color. For example, icons should be presented in different styles and not just different colors. Links need at least a 3:1 contrast from surrounding text and an additional differentiation is needed when the link is hovered over or receives focus (underline for example).

Responsive design

Even if you expect your users to only use one device (desktop for example), you should design with responsiveness in mind. As users zoom in, zoom out, or use a different design, the UI should respond and the web page should be usable.

Use %, em, and rem instead of pixels
Design with a responsive grid
- Use a meta viewport tag with width set to device-width and initial-scale set to 1.

<meta name="viewport" content="width=device-width, initial-scale=1">

With width, we are telling the viewport to match the width in device independent pixels
With initial-scale, we are setting a 1:1 ratio between CSS pixels and device independent pixels
DO NOT set max-scale to one or user-scalable to no. These are anti-patterns.
- Make sure you UI interactive elements have appropriate spacing around them to where they do not overlap and have enough padding to where users can click them when they’re mobile/touchscreen friendly.
Set the touch target to a minimum size of 48 device independent pixels. (This can include empty padding for smaller icons)
Set the margin around the touch target to a minimum of 32 device independent pixels to avoid users accidentally clicking one target while trying to click a different element.

Bonus: Styling the focus

This is not required for ADA compliance, but is definitely a nice touch and doesn’t take too much effort.

In CSS, you can use the pseudoclass :focus to style the focus ring all users can see (to see the focus ring, you will just tab through the page and everything it lands on will have a ring around it. If you don’t see the ring, you’ll need to check the tab order).

Example of pseudoclass and a basic focus ring:

:focus {
  outline: 1px dotted #FFF
}

*Do not set the outline to 0. Focus elements should be obvious.

For consistency, it is recommended that you use box-shadow instead of outline. In addition, if you already have CSS for hover, you can add most of focus to that so it behaves similarly to hovering.

Example of how you might use hover styling with focus:

/* we want both hover and focus to look similarly here, but only focus to have the ring */
button:hover, button:focus {
  background: #E91E63;
  color: #FFFFFF;
  text-decoration: underline;
}

/* here we're taking out the outline, but replacing it with a box shadow*/
/* we only want the focus ring to display when we're focused on it, not hovering*/
button:focus {
  outline: 0;
  box-shadow: 0 0 8px 3px rgba(255, 255, 255, 0.8);
}

Resources/tools I find very valuable

MVPS:

Web AIM Checklist
- This is such an important tool for evaluating a webpage. It really helps put success criteria to the WCAG and makes evaluation more simple
Web AIM
- This website is very informative and a solid example for a lot of accessibility concepts. All of the articles I’ve read here are straightforward and super helpful.
Udacity Web Accessibility Course
- This is a pretty quick course provided for free from Google engineers. It’s an amazing resource and will help you get the basics of web accessibility. I highly recommend completing that course.
WAVE Evaluation Tool or Lighthouse
- Both are very good tools for quickly assessing simple errors and color contrast in web pages. They are limited and most of the assessing will need to be done by hand, but these are wonderful starting places.
How To Do an Accessibility Review
- This article and accompanying video provide a great cheat sheet for conducting an accessibility review once you understand the basics.

Each of the above resources link to a ton of other helpful resources. For the purpose of this article, I wanted to keep the list smaller to avoid overwhelming. These five are definitely plenty to get started with.

Conclusion

We covered a lot in here! This is a great place to get started with accessibility, but remember that there is still a lot more to accessibility. If you take anything away from this, let it be that accessibility is all about enabling more users to access our content. It’s about user experience more than checking off a box.

Weekly Updates and a Change of Plan (I've Been Hired!)

TabathaSlatton — Sun, 31 Jan 2021 17:47:52 +0000

Yep, you heard that correctly, I've officially been hired! When I finished my coding Bootcamp two weeks ago, I did not expect things to happen so quickly. I'm, of course, very happy that they did! I was planning to hold off on saying anything because I know this doesn't happen to most Bootcamp grads this quickly, but with my weekly journals, I always want to come from a place of honesty. Please do not think that this is a normal thing that happens and feel bad if you've been looking for awhile. Yes, I worked my a$$ off to get here, but my niche background and pure luck went a long way as well. You see, I'm now working at a company I am familiar with. I've used their technology in my past career as a teacher and that very much helped get my foot in the door. With this in mind, let's review last week and preview the upcoming week.

Last Week Reflection

I started the week strong with reviewing JavaScript as well as Data Structures and Algorithms using a Udemy class. I did a peer mock interview on interviewing.io and practiced some coding challenges on Code Wars. This plan lasted all of two days as I was able to schedule my first real interview for Wednesday.

Interviewing at my New Company

As I stated in my introduction, I was actually hired on the spot during the interview I had on Wednesday. If you're like me, you like reading about the processes different people go through during these so I will briefly touch on that here. I did not have a Data Structures and Algorithms challenge as I expected based on articles and videos other developers have posted. Instead, it was a mix of a technical and behavioral interview where we went over one of my projects and I was asked questions that pertained to the position I applied to (SQL was a huge part of this particular job since it is mostly focused on Backend). We also discussed how I used their products from a teacher's perspective. Let me tell you this, I GENUINELY loved their products while I was teaching and actively helped other teachers use them. I led trainings in this product. Having a passion for what they do and combining my skills in programming with that unique perspective REALLY helped make me a viable candidate. If you take anything from this and you're a newer developer, take this: find something that makes you unique. Find your niche in the world and use that to help you.

The Rest of the Week

After my interview, I started work on Friday and used that to onboard at my new company. I started to set up my environment on my personal computer while I wait for the one they're sending me. I began to research the stack they use and found some courses that might be helpful to me as I learn these new languages on the job.

Next Week Preparation

This next week will be a very busy one. I plan to finish setting up my environment on Monday and begin with the basics of PHP/MySQL. Fortunately, I have used SQLite before and pick things up relatively quickly so my hope is to have a personal project built with PHP and MySQL by the end of the week. I will be given the documentation for a project they want me to start working on as well so my plan is to hammer out the details on that project and make sure I fully understand what the expectations are so I can begin creating a mockup/model out the database.

If I feel confident and comfortable with the above, my next plan would be to continue with data structures and algorithms practice with JavaScript so I can possibly enter a competition next weekend. I'm very interested in competitive programming and think it might be both a valuable and fun hobby for me to get into.

Resources I Plan to Use

Week of 1/18/21 Notes, Plan for Next Week

TabathaSlatton — Sun, 24 Jan 2021 17:16:37 +0000

Okay. Truth time. I'm a former teacher. As such, I over plan and I over plan HARD. I do so in part because while I was teaching, I quickly learned that the worst thing you can do is under-plan. Under-planning leads to boredom in students, boredom leads to chaos, and you're bound to have the Principal walk in the second your class turns on you. While I'm not a teacher anymore, I still find it incredibly difficult to break that habit. I'm also not super interested in breaking it because over-planning for one week allows me to push myself that week and carry over the unused plans for next week.

All this to say, if you look at my plans for the week and wonder to yourself how any human can possibly meet allll of those goals, let it be noted that 1) I never claimed to be a human and 2) As much as I really intend to get to everything, I always have my need tos, want tos, and will if I cans in the wayyy back of my head (I'm just not going to declare them because they change as the week goes on).

Without further delay.....

Last Week Reflection

Last week was what I will refer to as a wonderful roller coaster. I started off very strong by getting through the Free Code Camp Front End Libraries reading in two days. I felt pretty good about all of the content they had (mostly since I've built a react project and was mostly using FCC as a way to refresh on the basics and make sure I wasn't missing anything).

Favorite resource of the week

The Net Ninja's ongoing Full React Tutorial is an amazing resource and probably the best I've found for understanding React. During this video series, you learn updated react topics (including useState and useEffect) that are not found in some older articles or learning resources. You'll also be using these to build out a simple Blog application.

Mock Interview

My preparation for last week was with the goal of success on my mock interview with someone who is working at a top tier company. With these two resources, plus some of the interview articles I linked last week, I CRUSHED the React portion of my mock technical interview. Unfortunately, this is where the roller coaster of the week took a little bit of a slide. I've been so focused on learning what I need to for projects that I haven't gone as into depth with coding challenges/ Data Structures and Algorithms as I've needed to and it showed. While the React portion went smooth, the JavaScript coding challenge was...problematic. I was able to solve the problem, however, it was definitely nowhere near the most efficient solution. The interview feedback ended up being that if it was a real interview, it definitely wouldn't have been an immediate no, but it also wouldn't have been a we have to hire this person right now either.

Post-Interview

While I will admit, I was a bit sad for the rest of the day after my mock interview didn't go exactly as I hoped, I woke up the next day with renewed energy and determination. I scrapped the remainder of the week's plan and decided I needed to focus hard on Data Structures and Algorithms. I haven't had much time since then as my interview was Thursday, but since then I have studied Big O in multiple ways to make sure I understand it, I've started reading Cracking the Coding interview, I've started a Data Structures and Algorithms Course on Udemy, and I've been practicing coding challenges every day, while making sure I investigate how others are solving the problem after I complete my solution to ensure I'm actively learning as I'm solving these.

Next Week Preparation

Next week's plan is fairly simple. I want to finish reading Cracking the Coding Interview and a popular udemy course on data structures and algorithms, all while making sure to do at least a couple of coding challenges every day. This already is a lot, however, I'd really like to push myself to build a portfolio website using React only (while I understand that React is overkill for a project like this, it serves the dual purpose of keeping those skills sharp as well as giving me a portfolio page). I'd also love to review JavaScript documentation to refine those skills while I'm focusing the coding challenges on JavaScipt. (I'm thinking TypeScript the week after maybe, but I'm also trying not to think too far in advance.

Resources I Plan to Use

Cracking the Coding Interview
Udemy JavaScript Data Structures and Algorithms
JavaScript Documentation

Weekly Notes, Goals For Next Week

TabathaSlatton — Sun, 17 Jan 2021 17:13:44 +0000

Now that I have finished my structured coding Bootcamp, I want to use Sundays as an opportunity to reflect on my previous week's work and set goals for the next week. I'm looking forward to exploring new topics while I continue my job search.

Last Week

Last week I focused on finishing up my React/Redux project review, preparing for/taking my mock behavioral interview, and looking into what I'm going to want to spend my time learning now that I am finished with my last project.

What I learned/Overall Plan for the Next Few Months

There is a lot to learn in the realm of programming. I feel very fortunate to have a post-grad outline provided by my Bootcamp that I can customize to fit my own career goals. From digesting the information from the post-grad plan as well as countless articles, I've decided to take my plan one week at a time and focus on setting weekly learning topics based on my interests and job postings I'm interested in. I've also decided that I will be continuously working on new projects and using my new learning to advance my past projects.

Next Week

In the upcoming week, I have a mock technical interview, which I've chosen to do in React. To prepare for this, I am currently refreshing my understanding of React/Redux with Free Code Camp's Front End Libraries section. I am almost done with the reading/practice problems and plan to build all the practice projects and a front-end focused portfolio in the upcoming week. In addition to this, I've found a few resources on interview questions and hope to find some coding challenges to work through as well.

Resources I plan to use next week:

500 React Interview Questions
Frequently asked: React JS Interview Questions and Answers
Top 50 React Interview Questions You Must Prepare In 2021
Free Code Camp
React Documentation
Various Coding Challenges that I can find