Andy Stitt BlogThis blog includes articles about web development and accessibility.2023-08-11T00:00:00Zhttps://andystitt.com/Andy Stittandy@andystitt.comPracticing accessible app development with Ionic2023-08-11T00:00:00Zhttps://andystitt.com/blog/practicing-accessible-app-development-with-ionic/<p>I have had website development as part of my job responsibilities since 2008 and full time since 2016.</p>
<p>I don’t really have professional experience with application development, and it is something that I would like to look at as an option in the future.</p>
<p>Fellow accessibility professional <a href="https://toddl.dev/" target="_blank" rel="noreferrer noopener">Todd Libby</a> turned me on to the <a href="https://ionicframework.com/" target="_blank" rel="noreferrer noopener">Ionic Framework</a>, which is an accessible application development framework. You can use React, Angular, or Vue.</p>
<p>I have the most experience with React, so I chose that to build my first app. I have worked with React professionally recently to build a custom WordPress Gutenberg block, and I have experimented with creating headless WordPress and Drupal sites with Gatsby and NextJS connecting to a REST or GraphQL API.</p>
<p>I’ve done little projects off of tutorials such as a to-do list, a pounds-to-kilograms converter, and a weather app that fetches local forecast information from a weather API.</p>
<p>For this project, I wanted to build an app based around a passion of mine: meditation. I built a simple meditation timer app with two-minute, five-minute, and ten-minute timers.</p>
<p>I found a <a href="https://www.npmjs.com/package/react-timer-hook" target="_blank" rel="noreferrer noopener">custom React timer hook</a> for the timer functionality, and build out the rest using the Ionic framework structure and components.</p>
<p>Ionic allows you to build native mobile apps, but to start off, I’m sticking with making it a web app with PWA functionality (I’m still learning what that means). So for now, I have deployed it to Netlify.</p>
<p>You can <a href="https://andy-stitt-meditation-timer.netlify.app/tab1" target="_blank" rel="noreferrer noopener">check out the deployed app</a> as well as the <a href="https://github.com/andystitt829/meditation-timer" target="_blank" rel="noreferrer noopener">codebase on Github</a>.</p>
<p>I’ve tested the basics as far as accessibility, including color contrast and focus visibility. I have yet to dive into accessibility for an app that has text that constantly changes on the screen, such as when you have a timer that is counting down. I have a feeling that I will be learning more about ARIA live regions for this purpose.</p>
<p>I’ve also learned that TypeScript has a lot of nuances that JavaScript does not. I haven’t really learned what those differences are, so I have allowed JavaScript in the tsconfig.json file and changed .ts files to .js to get errors to go away. I will get good at TypeScript someday!</p>
Six common accessibility errors found on websites2023-06-07T00:00:00Zhttps://andystitt.com/blog/six-common-accessibility-errors-found-on-websites/<p><a href="https://webaim.org/projects/million/" target="_blank" rel="noreferrer noopener">The WebAIM Million report</a> scans the homepages of the top one million websites and reports its findings regarding accessibility errors. The six most common errors in these reports have been the same for the last five years that the report has been conducted.</p>
<p>These errors are easier to fix than other errors where you are dealing with more complex code and design patterns. This is part of the low-hanging fruit that you can target to make major progress when making accessibility fixes on existing sites and what to pay attention to when starting new projects.</p>
<p>Six common website accessibility errors are:</p>
<h2 id="low-contrast-text"><a class="heading-anchor" href="https://andystitt.com/blog/six-common-accessibility-errors-found-on-websites/#low-contrast-text">Low contrast text</a></h2>
<p>When people build websites without accessibility in mind, they don’t test the contrast of the font color against the background color to make sure that the contrast ratio is high enough. There are lots of color contrast checkers you can use. I use the <a href="https://webaim.org/resources/contrastchecker/" target="_blank" rel="noreferrer noopener">WebAIM Contrast Checker</a>.</p>
<p>This checker will let you know if you’ve passed or failed and at what level according to the Web Content Accessibility Guidelines, otherwise known as WCAG. At minimum, you need the colors to pass at the AA level. The AA level has its own minimum contrast ratio requirements, and the contrast ratio at the AAA level is even higher.</p>
<h2 id="missing-alternative-text-for-images"><a class="heading-anchor" href="https://andystitt.com/blog/six-common-accessibility-errors-found-on-websites/#missing-alternative-text-for-images">Missing alternative text for images</a></h2>
<p>When building accessible websites, the goal is information parity. Whatever information a sighted user can see on a website should also be able to be accessed by a blind or low-vision user that uses a screen reader.</p>
<p>Whatever a sighted user sees in an image should be described in that image’s alternative text. Try not to be under-descriptive or over-descriptive. Just describe what’s in the image; what you think people would want to know about it.</p>
<p>There are lots of schools of thought about how alternative text should be written, but the most important starting point for you is to put in the effort to begin with. You will get better at it over time.</p>
<p>There are images that are used strictly for decoration called decorative images, and these images don’t need alternative text. However, I’ve found that so many people forget or don’t know to put alternative text in any images at all. So, most images that you come across will need alternative text.</p>
<h2 id="empty-links"><a class="heading-anchor" href="https://andystitt.com/blog/six-common-accessibility-errors-found-on-websites/#empty-links">Empty links</a></h2>
<p>Most of the time, empty links occur when, in the HTML, you wrap an icon in <code><a></code> tags and there’s no accompanying text to identify what the link is going to.</p>
<p>For example, this can happen with Font Awesome icons. Let’s say you want to link to your Facebook page, and you use the Font Awesome icon to do it. This would be the HTML:</p>
<p><code><a href="https://facebook.com/your-facebook-page-URL"><i class="fa-brands fa-square-facebook"></i></a></code></p>
<p>This would trigger an accessibility error since there is no text describing what the link goes to.</p>
<p>There are a number of ways that you can fix this. You can add a title attribute to the <code><a></code> tag like this:</p>
<p><code><a href="https://facebook.com/your-facebook-page-URL" title="My Facebook page"><i class="fa-brands fa-square-facebook"></i></a></code></p>
<p>You can add an aria-label attribute to the <code><a></code> tag like this:</p>
<p><code><a href="https://facebook.com/your-facebook-page-URL" aria-label="My Facebook page"><i class="fa-brands fa-square-facebook"></i></a></code></p>
<p>Finally, you can add text that is invisible on the front-end of the website but visible to screen readers and other assistive technologies. This is commonly referred to as “screen reader-only text”. For example, if you use the Bootstrap framework, it has a CSS class called <code>.sr-only</code> that you can apply like this:</p>
<p><code><a href="https://facebook.com/your-facebook-page-URL"><span class="sr-only">My Facebook page</span><i class="fa-brands fa-square-facebook"></i></a></code></p>
<p>One practice that I use at work is to make sure that the Facebook icon is hidden from screen readers and other assistive technologies by adding the <code>aria-hidden="true"</code> attribute. The whole piece of code looks like this:</p>
<p><code><a href="https://facebook.com/your-facebook-page-URL"><span class="sr-only">My Facebook page</span><i class="fa-brands fa-square-facebook" aria-hidden="true"></i></a></code></p>
<p>There could be other ways of generating empty links, but this is the most common one that I see and how to fix it.</p>
<h2 id="missing-form-input-labels"><a class="heading-anchor" href="https://andystitt.com/blog/six-common-accessibility-errors-found-on-websites/#missing-form-input-labels">Missing form input labels</a></h2>
<p>Every time you put a form input box on a website, you need to give it a label. The easiest way to do this is to use the <code><label></code> tag. Here’s an example:</p>
<p><code><label for="first-name">First Name</label><input type="text" id="first-name"></code></p>
<p>Make sure that the <code><label></code> “for” attribute matches the <code><input></code> “id” attribute. That’s the only way to associate the label with the input box programmatically so that assistive technologies are able to announce the input box with the correct label.</p>
<p>Please note that the “placeholder” attribute in the <code><input></code> tag is not a replacement for a <code><label></code>. Though the placeholder text is visible to sighted users, as soon as they click their mouse or tab into the field using their keyboard and start typing, the placeholder text goes away. There needs to be a persistent label for the input field that doesn’t disappear when the user takes any kind of action.</p>
<h2 id="empty-buttons"><a class="heading-anchor" href="https://andystitt.com/blog/six-common-accessibility-errors-found-on-websites/#empty-buttons">Empty buttons</a></h2>
<p>This is very similar to empty links. Most of the time you will see buttons with icons and no other text get flagged by accessibility scanners as empty buttons. Just like with the <code><a></code> tag, you can use the “title” or “aria-label” attributes with the <code><button></code> tag or add screen reader-only text between <code><span></code> tags with the appropriate CSS class, such as <code>.sr-only</code> in Bootstrap.</p>
<h2 id="missing-document-language"><a class="heading-anchor" href="https://andystitt.com/blog/six-common-accessibility-errors-found-on-websites/#missing-document-language">Missing document language</a></h2>
<p>The <code><html></code> tag at the top of the document needs to have a “lang” attribute. If your website is in English, then the full code would be <code><html lang="en"></code>. Assistive technologies need to know what language to read the document in.</p>
<p>You can access a full list of language codes from the <a href="https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry" target="_blank" rel="noreferrer noopener">Internet Assigned Numbers Authority Language Subtag Registry</a>.</p>
<p>If you ever have a portion of a web page in a different language than the rest of it, then you can add the “lang” attribute to that portion of content only. For example, if you have a paragraph of text in Spanish on an otherwise English language page, then you can have <code><p lang="es"></code> as the beginning paragraph tag.</p>
<p>For fun, create a web page in English, put in a paragraph of Spanish content without changing the “lang” attribute for that paragraph, and test it in a screen reader. You’ll hear Spanish words read in an English/American accent, and many of the pronunciations won’t be even close to correct. This is why the “lang” attribute is so important.</p>
Getting started with screen reader testing2023-03-24T00:00:00Zhttps://andystitt.com/blog/getting-started-with-screen-reader-testing/<p>Though it is far from the only assistive technology that people use, screen readers are the most talked about ones in the digital accessibility world.</p>
<p>People who are blind or have low vision use screen readers, and sighted people who find personal benefits from screen readers use them too.</p>
<p>Testing your website content with screen readers can help identify accessibility errors in the websites you build. If a screen reader announces something in a weird way, or if it doesn’t announce anything at all even though it should, you can take note of what happened and investigate the steps needed to fix it.</p>
<h2 id="start-with-screen-readers-that-are-available-to-you"><a class="heading-anchor" href="https://andystitt.com/blog/getting-started-with-screen-reader-testing/#start-with-screen-readers-that-are-available-to-you">Start with screen readers that are available to you</a></h2>
<p>The best way to start testing your websites with screen readers is to start with the ones that are available to you.</p>
<p>If you’re using a Windows computer, <a href="https://support.microsoft.com/en-us/windows/complete-guide-to-narrator-e4397a0d-ef4f-b386-d8ae-c172f109bdb1" target="_blank" rel="noreferrer noopener">Narrator</a> is the screen reader that’s built into it.</p>
<p>The most recent <a href="https://webaim.org/projects/screenreadersurvey9/" target="_blank" rel="noreferrer noopener">screen reader user survey</a> put out by WebAIM shows that <a href="https://www.freedomscientific.com/products/software/jaws/" target="_blank" rel="noreferrer noopener">JAWS</a> and <a href="https://www.nvaccess.org/" target="_blank" rel="noreferrer noopener">NVDA</a> are the most highly used screen readers. Both are Windows-based. NVDA is free and JAWS is not, so your budget will dictate if JAWS is available to you.</p>
<p>Voiceover is the built-in screen reader for both <a href="https://support.apple.com/guide/voiceover/welcome/mac" target="_blank" rel="noreferrer noopener">Mac computers</a> and <a href="https://support.apple.com/guide/iphone/turn-on-and-practice-voiceover-iph3e2e415f/ios" target="_blank" rel="noreferrer noopener">iOS devices</a>.</p>
<p><a href="https://support.google.com/accessibility/android/answer/6283677?hl=en" target="_blank" rel="noreferrer noopener">TalkBack</a> is the screen reader that’s built into Android devices.</p>
<p>Whatever devices you have available to you, start with testing those screen readers. There are plenty of tutorials out there that you can watch to learn how to test with them.</p>
<p>One thing to watch out for is that if you’re not a native screen reader user, then you don’t have the lived experience to know the entirely of how native users use this technology. The main reason that you’re testing with a screen reader is to find the big obvious bugs that you can detect and fix.</p>
<p>Once you’ve done that, then your company, if it has the money and inclination, can pay disabled user testers to test your websites and give you information about bugs that you wouldn’t be able to find as a non-disabled person.</p>
<p>Start with what you have, learn, go forth, and test!</p>
Getting started with manual keyboard testing2023-02-13T00:00:00Zhttps://andystitt.com/blog/getting-started-with-manual-keyboard-testing/<p>Many website users don’t use a mouse to navigate websites. Instead, they use only their keyboard.</p>
<p>They may have a disability that involves their mobility and motor skills, and moving a mouse steadily enough to navigate a website isn’t an option for them. Using the tab and arrow keys on their keyboard works better for them.</p>
<p>It is important that we test the web pages that we build using a keyboard. Here are some things to look out for:</p>
<h2 id="make-sure-all-focusable-elements-are-accessible-by-keyboard"><a class="heading-anchor" href="https://andystitt.com/blog/getting-started-with-manual-keyboard-testing/#make-sure-all-focusable-elements-are-accessible-by-keyboard">Make sure all focusable elements are accessible by keyboard</a></h2>
<p>Focusable elements include links, buttons, and form fields. Anything that you can click on or click into with a mouse, you should be able to access it using the tab or arrow keys on your computer.</p>
<p>As you tab through elements, make sure you’re moving forwards and backwards. Holding down the shift key while pressing tab will allow you to move backwards through focusable elements.</p>
<h2 id="make-sure-there-are-no-keyboard-traps"><a class="heading-anchor" href="https://andystitt.com/blog/getting-started-with-manual-keyboard-testing/#make-sure-there-are-no-keyboard-traps">Make sure there are no keyboard traps</a></h2>
<p>If a page that you’re testing only has links, then you’re unlikely to find a keyboard trap. If a page you’re testing has more complex elements such as form fields or modal windows, you might find a keyboard trap.</p>
<p>A keyboard trap is a part of a website where no matter how many times you tab forwards and backwards, you can’t get out of a specific section abd back to other elements of the website.</p>
<p>It’s called a keyboard trap because keyboard focus becomes trapped in that section of the website. Make sure that the websites you develop don’t contain any keyboard traps by testing for them.</p>
<h2 id="make-sure-that-all-focusable-elements-have-a-visible-focus-outline"><a class="heading-anchor" href="https://andystitt.com/blog/getting-started-with-manual-keyboard-testing/#make-sure-that-all-focusable-elements-have-a-visible-focus-outline">Make sure that all focusable elements have a visible focus outline</a></h2>
<p>As you tab through different elements on the web page that you’re testing, look to see if you know which focusable element is receiving focus at that time. Does it change color? Does it have an outline around it? Are words underlined?</p>
<p>In order for content to be keyboard accessible, you have to know where you are and what is receiving keyboard focus at any given time. If you don’t know where you are, then you can write CSS styles for the elements that are not receiving focus, such as putting a visible outline around the element.</p>
<h2 id="make-sure-to-keyboard-test-mobile-screen-sizes"><a class="heading-anchor" href="https://andystitt.com/blog/getting-started-with-manual-keyboard-testing/#make-sure-to-keyboard-test-mobile-screen-sizes">Make sure to keyboard test mobile screen sizes</a></h2>
<p>Many users have keyboards for their mobile devices if their disabilities doesn’t allow for them to scroll, swipe, and tap with their fingers.</p>
<p>As far as I know, if you don’t have a keyboard for a mobile device, you can adjust the screen width in your desktop browser so the mobile version of the site appears and test with your computer keyboard.</p>
<h2 id="make-keyboard-testing-a-part-of-your-testing-toolbox"><a class="heading-anchor" href="https://andystitt.com/blog/getting-started-with-manual-keyboard-testing/#make-keyboard-testing-a-part-of-your-testing-toolbox">Make keyboard testing a part of your testing toolbox</a></h2>
<p><a href="https://andystitt.com/blog/getting-started-with-automated-accessibility-testing/">Automated accessibility testing</a> can quickly help pick up errors that are easily detectable. Manual testing detects errors that automated testing cannot. Keyboard testing is a key part of manual testing. It will help you make websites and applications that are more accessible if you keyboard test the code that you write as you write it.</p>
Getting started with automated accessibility testing2023-01-24T00:00:00Zhttps://andystitt.com/blog/getting-started-with-automated-accessibility-testing/<p>If you’re getting started on your accessibility journey as a web developer, one way to find errors in code that you’ve already written is through automated accessibility testing. There are tools that you can use to automatically detect errors in your code that you can then fix.</p>
<p>You can use these tools to scan sites that you’ve already built. You’re likely to find lots of errors that may take a good amount of time and effort to fix. This is what happens when sites are built and accessibility isn’t considered from the beginning. Take note of what you find and show it to your team for prioritizing.</p>
<p>You can also use these tools to scan your work as you’re building websites. Just like you would test new components, templates, and pages for cross-browser compatibility, you should also test them for accessibility. Errors found earlier in the process can be fixed more easily.</p>
<h2 id="my-two-favorite-automated-accessibility-testing-tools"><a class="heading-anchor" href="https://andystitt.com/blog/getting-started-with-automated-accessibility-testing/#my-two-favorite-automated-accessibility-testing-tools">My two favorite automated accessibility testing tools</a></h2>
<h3 id="webaim-wave"><a class="heading-anchor" href="https://andystitt.com/blog/getting-started-with-automated-accessibility-testing/#webaim-wave">WebAim WAVE</a></h3>
<p><a href="https://wave.webaim.org/" target="_blank" rel="noreferrer noopener">WebAim WAVE</a> is a great starting point for automated accessibility testing. You can put in the URL of a live website to evaluate it, or you can use the Firefox and Chrome extensions to run tests on live sites as well as sites in local and staging environments.</p>
<p>It will show you errors such as insufficient color contrasts, empty links and buttons, missing alternative text on images, empty headings, and form errors. It will also show you alerts that may not necessarily be errors but things are still worth looking into such as redundant alternative text, suspicious link text, and a missing first level heading.</p>
<h3 id="axe-devtools"><a class="heading-anchor" href="https://andystitt.com/blog/getting-started-with-automated-accessibility-testing/#axe-devtools">axe DevTools</a></h3>
<p><a href="https://www.deque.com/axe/devtools/" target="_blank" rel="noreferrer noopener">axe DevTools</a> is a Chrome extension made by the company Deque. It shows a lot of the same errors and warnings that WebAim WAVE does, but I find that it’s better at showing deeper code level issues. I’ve found errors with how ARIA is implemented in axe DevTools that WebAim WAVE did not show me.</p>
<h2 id="limitations-of-automated-accessibility-testing-tools"><a class="heading-anchor" href="https://andystitt.com/blog/getting-started-with-automated-accessibility-testing/#limitations-of-automated-accessibility-testing-tools">Limitations of automated accessibility testing tools</a></h2>
<p>WebAim WAVE, axe DevTools, and other automated tools like it only find a small fraction of accessibility errors. They are no substitute for manual testing, including testing using a keyboard only and with a screen reader.</p>
<p>For example, automated testing tools cannot show that an element on the screen cannot be accessed by your keyboard, or that there’s a keyboard trap, or whether or not a skip-link works properly. Only manual testing will show you those things.</p>
<p>Use automated testing tools as your starting point. Use it to start surfacing issues that you can immediately tackle. Make it a habit of doing it whenever you write code in addition to auditing your past work.</p>
Lessons learned in my accessibility journey2023-01-12T00:00:00Zhttps://andystitt.com/blog/lessons-learned-in-my-accessibility-journey/<p>As of this writing, I have been focusing on accessibility as part of my job as a web developer for almost two years.</p>
<p>The only thing I knew before then was that I was supposed to write alt text for images, and even then I did it very badly (“Picture of [insert image subject here]” is not very descriptive).</p>
<p>Over the last two years, I have learned about <a href="https://www.w3.org/TR/WCAG21/" target="_blank" rel="noreferrer noopener">WCAG success crtieria</a>, automated and manual testing, prioritizing accessibility as early in the process as possible (as in right away), and just having people with disabilities at the top of my mind as I build things that people will use.</p>
<p>Here are the major lessons that I’ve learned in my accessibility journey:</p>
<h2 id="accessibility-is-everybodys-job"><a class="heading-anchor" href="https://andystitt.com/blog/lessons-learned-in-my-accessibility-journey/#accessibility-is-everybodys-job">Accessibility is everybody’s job</a></h2>
<p>WCAG stands for Web Content Accessibility Guidelines. Everyone that has anything to do with building a website and putting content on it is responsible for the content’s accessibility.</p>
<p>Lots of people think that accessibility is the developer’s job only. WCAG does not stand for Web Code Accessibility Guidelines. Code is part of the content, but developers are not the only ones responsible for accessibility.</p>
<p>So are designers. So are content writers and editors. So are their managers. So are the company leaders.</p>
<p>Every single person who has anything to do with building a product that people use is responsible for accessibility.</p>
<h2 id="there-is-so-much-work-to-do"><a class="heading-anchor" href="https://andystitt.com/blog/lessons-learned-in-my-accessibility-journey/#there-is-so-much-work-to-do">There is so much work to do</a></h2>
<p>Even though the WCAG standards have been around for over 20 years, way too many people don’t pay attention to them and develop websites for sighted, able-bodied, neurotypical users who use a web browser, a keyboard, and a mouse to navigate websites. How people with disabilities would interact with their websites never even crosses their mind.</p>
<p>That’s why there is so much work to do.</p>
<p>It took the pandemic to even bring accessibility to my attention, and since then, <a href="https://www.wsj.com/articles/more-companies-are-looking-to-hire-accessibility-specialists-11630501200" target="_blank" rel="noreferrer noopener">hiring for accessibility specialist roles has increased</a>.</p>
<p>It’s a shame that this didn’t happen sooner. It’s wild to think that I was only ten years old when the Americans with Disabilities Act was passed in 1990. Historically, and I can only speak for my home country of the United States, disabled people have not been treated well. Their lives have not been valued.</p>
<p>Even with the ADA being over 30 years old and the WCAG standards being over 20 years old, there is still so much work to do and so many inaccessible websites to fix and new accessible websites to be built.</p>
<p>The work has to be done, and we must do it, together, collectively. There is no other option.</p>
<h2 id="there-is-so-much-low-hanging-fruit"><a class="heading-anchor" href="https://andystitt.com/blog/lessons-learned-in-my-accessibility-journey/#there-is-so-much-low-hanging-fruit">There is so much low-hanging fruit</a></h2>
<p>As developers, one of the strongest tools in your box for writing accessible code is semantic HTML. Things like <code><header></code>, <code><main></code>, and <code><footer></code>, which help assistive technologies announce to the user what section of the website they’re in, are incredibly helpful and simple to implement.</p>
<p>Because of the proliferation of the use of JavaScript and its frameworks, and social media influencers and gatekeepers saying that HTML isn’t “real programming”, there are so many applications that have inaccessible HTML.</p>
<p>Another example that I’ve had to deal with is the lack of use of the <code><button></code> tag. I have seen what is supposed to be a button coded using <code><span></code> tags and the button’s functionality programmed using JavaScript.</p>
<p>The problem is that the JavaScript that was used only accounted for mouse clicks. Not everyone uses a mouse. Some people only use their keyboard. When I tabbed to the button using my keyboard and then tried hitting the return key and spacebar, nothing happened.</p>
<p>Instead of programming functionality for a <code><span></code> tag, you can use a <code><button></code> tag which browsers and assistive technologies already recognize and know what to do with it. No extra functionality needed.</p>
<p>There’s a lot of low-hanging fruit like this just with fixing semantic HTML. You can make small and large improvements just by fixing these kinds of things up.</p>
<h2 id="you-need-disabled-user-testers-to-validate-the-accessibility-of-your-websites"><a class="heading-anchor" href="https://andystitt.com/blog/lessons-learned-in-my-accessibility-journey/#you-need-disabled-user-testers-to-validate-the-accessibility-of-your-websites">You need disabled user testers to validate the accessibility of your websites</a></h2>
<p>I am now at the stage where I need to work with disabled user testers on the websites that my team builds.</p>
<p>My team is so conscientious of accessibility now that, while we’re not perfect and we miss things, we hit a whole lot of our marks. I find myself having conversations with one of my fellow developers about the best way to build a particular interface to make it as accessible and usable as possible.</p>
<p>We test what we build with screenreaders and ponder if there’s anything that we’re missing.</p>
<p>The fact is: we don’t know because we’re not native screenreader users and we’re not disabled website users. We have gone as far as we can with making sure that we have the bare minimum of accessibility covered, and now we need disabled user testers to help take our websites’ accessibility and usability to the next level.</p>
<p>One thing that I have heard the disability community repeat when it comes to people who build websites and focus on accessibility: “nothing about us without us.” Of course. That makes perfect sense. If we’re focusing on building websites that people with disabilities can access, then of course people with disabilities should be in the room.</p>
<h2 id="come-jump-on-the-accessibility-train!"><a class="heading-anchor" href="https://andystitt.com/blog/lessons-learned-in-my-accessibility-journey/#come-jump-on-the-accessibility-train!">Come jump on the accessibility train!</a></h2>
<p>Those are the biggest lessons that I’ve learned since diving into accessibility almost two years ago. When you first jump in, it can seem really intimidating. There’s so much to do and so much to know.</p>
<p>But you’re not alone. You can’t do it alone. It’s not your responsibility to do it alone.</p>
<p>Do your best to find people who are also dedicated to making the web a more accessible place. It could be at your job. It could be in online communities. Feel free to reach out to me at one of my social media links in the footer of this website and let me know if you have any questions!</p>
Making a difference focusing on web accessibility2023-01-04T00:00:00Zhttps://andystitt.com/blog/making-a-difference-focusing-on-web-accessibility/<p>I have developed for the web professionally since 2008 and have done so full-time since 2016.</p>
<p>I only discovered web accessibility in 2021. Before that, I did add alt text to images, but not always and usually very badly.</p>
<p>Web accessibility does not get nearly the attention and respect that it deserves. Prioritizing accessibility in the creation of websites helps ensure that people with disabilities have equal access to information.</p>
<p>It took COVID-19 and everyone having to stay home during the early shut-downs for accessibility to come to the forefront of many people’s attention, including mine.</p>
<p>If you look at reports, such as <a href="https://webaim.org/projects/million/" target="_blank" rel="noreferrer noopener">The WebAim Million</a>, you will find that the overall state of web accessibility is pretty dismal. The 2022 WebAim Million report showed that 96.8% of the top one million homepages had detected WCAG 2 failures. WCAG stands for Web Content Accessibility Guidelines, which is the standard that most professionals test against for accessibility.</p>
<p>If almost 97% of the top one million homepages have detected accessibility failures, then we have a lot of work to do. The fact that we have a lot of work to do means that you can jump in and contribute immediately.</p>
<p>I’m in my second year of focusing on accessibility as a web developer. I have found that it isn’t incredibly difficult. Accessibility tends to favor simplicity over complexity as far as code is concerned. Use the tools that the browser and HTML, CSS, and JavaScript already give you. Supplement with ARIA where needed. And, as always, test, test, and test some more!</p>
<p>I will be blogging about how you can incorporate accessibility practices in your development work. This includes the coding and testing that you do as well as collaborating with other members of your team (including designers, developers, writers, project managers, etc.) to ensure accessibility is considered throughout your projects.</p>
<p>I’ll go over the simple things that you can start doing right now as well as the more complex things, such as getting buy-in from your teammates and clients, that may take more time and a concerted effort.</p>
<p>We need you in the fight to make the web more accessible for people with disabilities. We have an incredibly long way to go. It is not only one person’s responsibility; we all need to participate. I hope to make it easier for you to participate and join the next generation of web professionals that prioritize accessibility!</p>