Web accessibility is following best practices in the building of websites to make it easily navigable for visitors, regardless of their unique conditions. Basically, every person that can visit a website should be able to use your website for its intended purpose. This is easier for some websites, like a blog. It is harder for others, like highly interactive and tooling web apps such as Figma. A visually impaired individual would find it difficult to create wireframes on Figma. However, it is a software developer's job to make sure that these unique conditions do not stop a person from using a website optimally if they do not have to.
There are standards regarding web accessibility. This is contained in the Web Content Accessibility Guidelines (WCAG). The entire idea is a set of universally accepted principles that should be followed while building particular components of the web. By doing this, persons with disabilities become able to more easily access the websites. There are two obvious benefits to this: it is the ethically right thing to do and it gives you a wider audience. There are three levels of accessibility. A, AA, and AAA. The more the number of A's, the more requirements there are, and consequently the more accessible the website. An accessible website should at least comply with the AA guidelines.
Here are a couple of observations I've made. First, navigation without a mouse. Second, live regions. Third, semantic html. These are tiny islands in the ocean that is accessibility. However, they are the areas I've considered most often recently.
Navigation without a mouse seems obvious for accessibility. However, it is just as easy for people without disabilities to forget because they do not have these conditions. A visually impaired individual will struggle more with using a mouse to navigate a webpage. This is why they have the option of navigating with a keyboard instead. A developer's job is to ensure that the experience while doing this is as easy as possible. This includes making certain components tabable and using the enter keypress listener as an alternative for the mouse click listener. The browser already makes some elements tabable, such as buttons and links. However, if the developer creates an element that does something when clicked with a non-tabable element, the developer should make it tabable. Setting the tab index attribute to "0" makes the element tabable. Setting it to "-1" makes it non-tabable. Simply doing this can help visitors navigate the website with the Tab key rather than the mouse.
Second, live regions. Live regions are areas on the webpage where the content actively changes after the website has been loaded. This may be ignored by screen readers. However, it is important for the developer to call the browser's attention to it. By adding an aria-live attribute to the container, the browser takes note of this. Generally, the developer should use aria-live="polite". However, aria-live="assertive" may be used in some cases. The Mozilla Developer Network documentation is clear on the differences and when each one should be used.
Semantic html is important to screen readers. They help the screen readers understand the structure of the webpage. When the screen reader understands it better, it can communicate it more clearly to the user. This means not throwing div and span tags in all parts of the website. Other proper tags, such as the article tag, aside tag, header tag, footer tag, and main tag should be considered.
In all, accessibility is an important part of web development that should be considered by developers. It should be done while developing the webpage rather than after the fact. It is also fairly easy to do once the developer bears it in mind while building the webpage.
Top comments (2)
This is a nicely detailed article that brings one "home" again on the aspects of accessability, thanks Fawaz! (Monae, you might be interested in this, too.)
There's also a very nice tool available for both Chrome and Edge browsers, called axe DevTools from Deque. They have both free and paid versions available with great documentation and usecase discussions etc.
Their portfolio includes accessibility testers for both Anroid and iOS platforms too.
Worth the look I think. I personally love Firefox's Dev browser and look forward to the day they might release their tool for it as well.
As someone who's currently diving deeper into accessibility, this article was really helpful!