# Don't Develop Just for Yourself - A Developer's Checklist to Accessibility

DevFeed: [Don't Develop Just for Yourself - A Developer's Checklist to Accessibility](<https://devfeed.tech/articles/don-t-develop-just-for-yourself-a-developer-s-checklist-to-accessibility-38434.md>)

Original publisher: [Read original article](<https://eevis.codes/blog/2021-05-28/dont-develop-just-for-yourself-a-developers-checklist-to-accessibility/>)

Author: Eevis Panula

Published: 2023-01-03T08:57:24.089000Z

Content type: tutorial

Language: en

Sources: [Eevis Blog](<https://devfeed.tech/sources/eevis-blog.md>)

Topics: [Accessibility](<https://devfeed.tech/topics/accessibility.md>), [keyboard](<https://devfeed.tech/topics/keyboard.md>), [Usability](<https://devfeed.tech/topics/usability.md>), [alt text](<https://devfeed.tech/topics/alt-text.md>), [aria](<https://devfeed.tech/topics/aria.md>), [ui](<https://devfeed.tech/topics/ui.md>)

Tags: [accessibility](<https://devfeed.tech/tags/accessibility.md>), [alt-text](<https://devfeed.tech/tags/alt-text.md>), [aria](<https://devfeed.tech/tags/aria.md>), [authoring](<https://devfeed.tech/tags/authoring.md>), [automated](<https://devfeed.tech/tags/automated.md>), [blog-post](<https://devfeed.tech/tags/blog-post.md>), [developer](<https://devfeed.tech/tags/developer.md>), [keyboard](<https://devfeed.tech/tags/keyboard.md>), [testing](<https://devfeed.tech/tags/testing.md>), [usability](<https://devfeed.tech/tags/usability.md>), [web](<https://devfeed.tech/tags/web.md>), [website](<https://devfeed.tech/tags/website.md>)

## AI overview

A beginner-oriented accessibility checklist for developers. It recommends manually testing keyboard navigation, focus visibility, and other website interactions after automated testing, while noting that the process does not guarantee full accessibility.

## Source excerpt

We, as developers, tend to develop sites unconsciously for people like ourselves. If we don't actively pay attention, the sites are often accessible only for certain types of people: Sighted mouse-users, who have good fine motor skills and are good at using computers. It leads to moments where no one who navigates the web with only a keyboard (or keyboard simulating device) can access and interact with the site. It is a pretty big group of people! We have a responsibility to make sites that work for all of our users. In some cases, it is required by law, but it is not the only reason we should care. This blog post is aimed for those at the beginning of their accessibility journey. You might know some things, like "always provide an alt-text for an image," but are unsure what to write there. Or you don't have any idea how to know if your site is accessible at all. Following this blog post won't make your site 100% accessible! The goal of this post is to provide some information about some things to check manually after using some automated testing. Keyboard Navigation First of all, abandon your mouse for a second. Don't use it. Try to navigate through the website using only the keyboard. Try to complete every task user needs to be able to complete on the website. Can you do it? Can you see where you are at the moment? Is the focus indicator (yes, that thing many designers and developers like to remove) visible enough? If you can't use the whole website with only a keyboard, that is an accessibility and usability problem. However, one thing to note here is that keyboard interaction is not necessarily accomplished with just tab and enter, as it has been at some point. The general pattern goes, as WAI-ARIA Authoring Practices state: A primary keyboard navigation convention common across all platforms is that the tab and shift+tab keys move focus from one UI component to another while other keys, primarily the arrow keys, move focus inside of components that include mult