Skip to main content

Obtained Verified Certificate for Introduction to Web Accessibility

 

I just completed a course in Web Accessibility and obtained a certificate.  This was a really cool course!  


Once upon a time, the internet was perceived as separate from 'real life,' with distinct 'IRL' experiences and online interactions. Over time, these realms have intertwined, blurring the lines between virtual and physical existence. Today, the internet is seamlessly integrated into our daily lives, becoming an indispensable part of modern society. Prioritizing accessibility is crucial to ensure that everyone, regardless of ability, has equitable access to the digital world.

While this course has given me a solid foundation in accessibility, there’s always more to learn. Accessibility isn’t just for people with disabilities; it’s for everyone. It’s about improving the web for all users.


Here is some of what I learned:

Making the Web Accessible for Everyone: A Deep Dive into Accessibility

Accessibility is crucial for creating top-notch websites and apps that are inclusive and user-friendly for everyone. As Tim Berners-Lee, the pioneer of the web, said in the 1990s: “The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.” Accessibility goes beyond a checklist—it's about real people and their lived experiences. It’s about breaking down barriers so that people with disabilities can fully engage with and benefit from the web. Many disabilities are invisible, and you can’t always tell if someone has a disability just by looking at them.

Did you know that the United Nations Convention on the Rights of Persons with Disabilities (UN CRPD) defines access to information and communications technologies, including the Web, as a basic human right? That’s pretty significant! With about 15%-20% of people worldwide having some form of disability, that’s over 1 billion people who need web access to be accessible.

Web accessibility covers various types of disabilities that might affect how someone interacts with the web:

  • Auditory
  • Cognitive
  • Neurological
  • Physical
  • Speech
  • Visual

One of the simplest ways to ensure your webpage or app is accessible is to make sure it can be navigated without a mouse. Here’s how to navigate using just a keyboard:

  • Tab key moves to the next link, form element, or button.
  • Shift+Tab moves to the previous link, form element, or button.
  • Enter activates the current link or button.
  • Try the arrow keys, Escape key, spacebar, and other keys too.

Text Wrapping: When building your site, avoid making users scroll both horizontally and vertically to read your content. This can be particularly challenging for people with motor impairments or cognitive disabilities. Keeping things simple and easy to navigate benefits everyone.

Screen Readers: These are essential tools not just for those who are completely blind. They also assist people with low vision and those who find it easier to process information audibly. For individuals who are both deaf and blind, screen readers work with dynamic braille displays. Screen readers also help those with cognitive disabilities who might struggle with visual information.

Closed Captions/Subtitles: Captions are a lifesaver for those who are hard of hearing but are also useful in noisy environments or for those watching in a non-native language. A study by The Office of Communications (Ofcom) found that 80% of TV viewers use subtitles for reasons other than hearing loss. That’s a significant portion of the population!

Keyboard Accessibility: Ensuring your website or app is navigable by keyboard is crucial. Many users rely on keyboard navigation, including those using speech input or other assistive technologies. Clear indicators for focus state and focus order are essential. Adding a ‘Skip to Main Content’ link can significantly enhance the user experience.

Switch Controls: These tools are invaluable for individuals with limited or no upper body mobility and for those with cognitive or learning disabilities. Types include sip-and-puff switches, button switches, camera switches, and eye tracking.

Speech Recognition Software: This software allows users to dictate text, search the web, send emails, and control devices. Ensuring that your code is clear and well-ordered helps avoid common issues with unclear links, buttons, and focus order.

Audio Description (AD): For those with visual impairments, meaningful alt text and audio descriptions of multimedia are crucial. This helps users fully understand what's happening on the screen.

Screen Magnification: Users who need to magnify the screen often struggle with navigation. Make sure that on-screen changes are obvious and that important content isn’t hidden in hover states or tooltips. Responsive design helps by allowing content to resize effectively.

Small Touch Targets: Small touch targets can be a challenge, especially for individuals with dexterity issues or tremors. Designing with larger, more accessible touch targets can make a big difference.

Design Mismatches: Disability often arises from a mismatch between design and the individual, rather than the person’s abilities. People with varying abilities use different strategies and assistive technologies, and there’s no one-size-fits-all solution.

Color and Contrast: Color isn’t just about aesthetics. Ensure good color contrast and don’t rely solely on color to convey information. This helps users with color vision deficiencies and those in different lighting conditions.

Accessibility extends beyond users with disabilities to include those using various devices like mobile phones, smartwatches, and aging individuals experiencing changing abilities. Transcripts and captions are beneficial for a wide audience. Did you know that 71% of students without hearing issues use captions to enhance focus and understanding?

The Web Accessibility Initiative (WAI) provides three sets of guidelines:

  • Web Content Accessibility Guidelines (WCAG)
  • Authoring Tool Accessibility Guidelines (ATAG)
  • User Agent Accessibility Guidelines (UAAG)

Everyone involved in the software development lifecycle has a role in accessibility, from product owners to developers, QA testers, and content editors. Accessibility should be considered from the start of the development process and be an ongoing learning journey.



Disability is caused by a mismatch between the design and the person.




I had a whole lot more written here that I lost when I crashed my computer playing around with the web developer toolbar 😩
Anyway, lets continue! 😁


Guideline 1.4 Distinguishable of WCAG says:
Make it easier for users to see and hear content including separating foreground from background.

Here are some ways to make sure content stands out:

  • Don't rely solely on color to give info or identify things
  • Use colors for text and background that contrast well
  • Make sure text stays readable when users make it bigger or change the spacing
  • Let text adjust when the window is small or when users zoom in
  • Try to use real text instead of text in pictures, or make sure pictures of text can be resized
  • Give users controls to stop, start, or adjust the volume of audio on the site
  • Keep background audio soft or let users turn it off to avoid distractions
There are tools available to help you figure out the contrast ratio and pick the right colors. Text should have a contrast ratio of at least 4.5:1, and ideally 7:1. For things like charts or big text, a 3:1 ratio might be okay

Guideline 2.1 Keyboard Accessible of WCAG says:

Make all functionality available from a keyboard.

Ensuring that all webpage functions can be accessed via keyboard is crucial, as many individuals rely on keyboard navigation. This also benefits users who employ speech input or various assistive technologies, enhancing accessibility for a wider audience. We want to ensure keyboard accessibility and visual focus for the following elements: links, form fields, media controls, and modals.

Guideline 2.2 Enough Time of WCAG says:

Provide users enough time to read and use content. 

People read and comprehend information at different rates. Personally, I notice variations in my own reading and understanding abilities depending on factors like fatigue or whether I've had a meal. Some days, I absorb information quickly, while on others, I find myself needing to read things multiple times for it to sink in.

Guideline 2.3 Seizures and Physical Reactions of WCAG says:

Do not design content in a way that is known to cause seizures or physical reactions.

We need to make sure our content does not flash or blink more than 3 times per second. This could trigger a seizure or other photosensitive reaction.  We need to be sure that if we are using animations or moving content that it isn't going to cause our users to be nauseous or uncomfortable, so keep the auto-play to less than 5 seconds and it's a good idea to have a way for the user to turn it off.

Guideline 2.4 of WCAG says:

Provide ways to help users navigate, find content, and determine where they are.

Remember, it's crucial to prioritize accessibility in coding right from the start. A well-structured design enhances navigation efficiency. Users engage with content in diverse ways, underscoring the need for clear and effective structural elements.

Guideline 2.5 Input Modalities of WCAG says:

Make it easier for users to operate functionality through various inputs beyond keyboard.

We need to be sure that we are designing functionality in such a way as to be able to accept input from a variety of different input modalities. Enlarging the click areas around buttons, links, and other controls benefits individuals with low dexterity using a mouse, as well as those navigating touch screens. Also, gestures such as shaking or tapping are becoming more common. There are more modalities than just a keyboard or mouse to interact with the web. Touchscreens are. becoming very common, and not just for mobile phones, but also information stands, kiosks, and more.

Guideline 3.1 Readable of WCAG says:

Make text content readable and understandable.

We want out users to be able to understand out content!  If there are abbreviations, unusual, or complex terms it's helpful to include explanations.  We also want to be sure the language we are using is able to be understood by ours users and isn't filled with large complex words, unusual phrases, and idioms.  We want to use simple, clear language.  This may look different depending on our audience and language. Something that's really cool is we can set the default language for our content right in the HTML.

Guideline 3.2 Predictable of WCAG says:

Make Web pages appear and operate in predictable ways.
When building our webpage or application, it's essential to maintain consistent navigation to prevent user confusion and frustration. It's also important to use the same names for buttons and controls throughout to keep things clear and simple for everyone.

Guideline 3.3 Input Assistance of WCAG says:

Help users avoid and correct mistakes.

Good instructions are incredibly important!  We want clear labels and clear instructions so that our users understand their purpose and use.  We also want good error messages that are helpful for our users.  Sat for example a users is filling out a form and they put the date in wrong.  Instead of the error message merely stating that the date was put in wrong, it should prompt the user to put the date in the correct format, we want our users to succeed.

It's important to make sure that when we have forms or other things for our users to fill out that we remember to build them with accessibility in mind from the very beginning.  We want clear labels and instructions, and to be sure that our users can interact with them using only their keyboard, or using voice input, and also using screen readers.


Guideline 4.1 Compatible  of WCAG says:

Maximize compatibility with current and future user agents, including assistive technologies.

We want our users to be able to access our content however and wherever suits them best.  We need to be sure our content is compatible with different browsers and assistive technologies such as screen magnifiers, screen readers, and speech recognition software.  


Accessibility is not just for the developer, everyone on the software development team has a role to play in accessibility.  Als, accessibility training isn't some once-off do it and forget it activity.  This is something that is important to keep learning about and we must keep ourself up to date.

While I can't claim this course has made me an expert in accessibility, it has provided me with a solid foundation and taught me a great deal. I'm eager to continue learning and growing in this field. Accessibility isn't just for people with disabilities—it's for everyone. It's about making things better for all people.


Don't forget to POUR

P - perceivable, the user must be able to perceive the information being presented, it cannot be invisible.

O - operable, users must be able to operate the interface, he interface cannot require interactions that the user cannot perform.

U - understandable, users must be able to understand the informations, they must also be able to understand how to operate the use interface

R - robust, this means that user must be able to access your content regardless of what method they are using to consume your content.

Some Tips:

1. Knowledge is power

2. Take it one step at a time

3. People first!  Accessibility is about people after all, ensuring equal access for everyone

4. Accessibility benefits everyone!


Further reading: 

Lots and lots and lots of links!  Soooooooooooooo many links:  How People with Disabilities Use the WebTool TipKeyboard AccessibilityBe ConsistentA Web of AnxietyCognitive Accessibility 103 The Business Case for Digital Accessibility,  Electronic Curb Cuts Have Benefits for AllAlexander Graham Bell; History.comPellegrino TurriOlder Users and Web Accessibility: Meeting the Needs of Ageing Web UsersW3C WAI "More than "Mobile",  Accessibility in User-Centered DesignMIT Libraries: The role of accessibility in a universal webW3C WAI: Web Accessibility Laws & PoliciesThe Business Case for Digital AccessibilityContent is easier to see and hear (in Accessibility Principles)Content is available from a keyboard (in Accessibility Principles)Users have enough time to read and use the content (in Accessibility Principles)Carousels Web Accessibility TutorialContent does not cause seizures and physical reactions (in Accessibility Principles)Users can easily navigate, find content, and determine where they are (in Accessibility Principles)Users can use different input modalities beyond keyboard (in Accessibility Principles)Text is readable and understandable (in Accessibility Principles)Content appears and operates in predictable ways (in Accessibility Principles)Users are helped to avoid and correct mistakes (in Accessibility Principles)Forms Web Accessibility TutorialHow to Meet WCAG (Quick Reference)Easy Checks — A First Review of Web Accessibility —Website Accessibility Conformance Evaluation Methodology (WCAG-EM)Tips for Getting StartedDeveloping an Organizational Policy on Web AccessibilityYour Role in AccessibilityWebsite Accessibility Conformance Evaluation Methodology (WCAG-EM)Involving Users in Web Projects for Better, Easier AccessibilityInvolving Users in Evaluating Web Accessibility

Table of the standard keystrokes:

Interaction

Keystrokes

Navigate to most elements

  • Tab
  • Shift + Tab - navigate backward

Link

Enter

Button

Enter or Spacebar

Checkbox

Spacebar - check/uncheck a checkbox

Radio buttons

  • ↑/↓ or ←/→ - select an option
  • Tab - move to the next element

Select (dropdown) menu

  • ↑/↓ - navigate between menu options
  • Spacebar - expand

Autocomplete

  • Type to begin filtering
  • ↑/↓ - navigate to an option
  • Enter - select an option

Dialog

Esc - close

Slider

  • ↑/↓ or ←/→ - increase or decrease slider value
  • Home/End - beginning or end

Menu bar

  • ↑/↓ - Previous/next menu option
  • Enter - expand the menu (optional) and select an option.
  • ←/→ - expand/collapse submenu

Tab panel

  • Tab - once to navigate into the group of tabs and once to navigate out of the group of tabs
  • ↑/↓ or ←/→ - previous/next tab.

'Tree' menu

  • ↑/↓ - Navigate Previous/next menu option
  • ←/→ - expand/collapse submenu, move up/down one level

Scroll

  • ↑/↓ - scroll vertically
  • ←/→ - scroll horizontally
  • Spacebar/Shift + Spacebar - scroll by page



Comments

Popular posts from this blog

Allow Me To Introduce Myself

Hello and good morning!   My name is Adriana K Williams, and I am embarking on a grand new journey. A little about Me: I am Toltec, my motto is Life is Art. I did not follow a traditional career path. Throughout my upbringing, I kept hearing adults say that if you do what you love, you'll never work a day in your life. If circumstances had been different, I would have gone to university. I would have loved to spend a few years studying philosophy, art, history, and science. However, I couldn't justify the cost of this experience since I wasn't focused on a specific career after graduation; I simply wanted to explore and learn because I love learning. So, I started working in restaurants because of my passion for food, and later became a roadie selling merchandise for touring bands across North America. I worked tirelessly at these jobs, but I genuinely loved what I did. I was fortunate to attend a show almost every night for a month or two at a time while on tour, meet peop

Solo Capstone Project for Devmountain QRPT14

  Link to slide show: Slideshow Adriana K Williams Solo Capstone Project  The website I tested: https://www.powwows.com/ My Favorite Test Case Find a PowWow Near You Search Without Entering Any Information I really enjoy negative testing.  I like to ask the question, ‘Will this allow me to _____?’ and then check to see whether the application behaves as anticipated, or if there might be a hidden vulnerability that could allow me to bypass the expected flow. My Favorite Bugs I found my favorite bug while testing the first feature during my initial exploratory testing.  If you try to search for a Pow Wow by Month, Year, and State or Province from the home page you’ll find you’re unable to select the year 2024.  My second favorite bug goes along with this one.  If you click the PowWows.com icon that is supposed to take you home from the calendar page you aren’t brought back to the homepage, but to a Pow Wow Calendar instead. My Least Favorite Part My least favorite part of t

Coding Basics Capstone Project

  I probably won't ever build anything else (just try and break what someone else made 😉) I really enjoyed the basics of coding course I took through Devmountain.  I found the HTML to be intuitive, the CSS to be loads of fun, and the JavaScript to be mind-bending. My Silly Little Webpage   👈 Link to see what I made HTML: <header>   <div class="logo-header">     <h2 class="different">And Now For Something       <br />Completely Different     </h2>     <img class="logo" src="https://i0.wp.com/www.adtothebone.com/blogpix/obliteratingfoot62470.jpg?w=625" alt="Monty Python Foot" width=325px />   </div>   <nav class="navigation">     <a class="navi">SPAM SPAM SPAM SPAM</a>     <a class="navi">The Spanish Inquisition</a>     <a class="navi">The Holey Grail</a>     <a class="navi">Lumberjack       &l