Resource Difficulty HTML Difficulty CSS Difficulty Javascript Difficulty Jquery Difficulty
Building Accessible Timeline Code ?/5 ?/5 ?/5 ?/5 ?/5

Building Accessible Timeline Code

Accessibility Resources

Intro

The internet is for everyone! I love the idea of everyone being able to have their little slice of the web outside of evil social media corporations' grasp, and that's why I'm creating a small guide as an introduction to web accessiblity! We should be making our sites accessible so that anyone, regardless of disability, can enjoy a smaller, more personal internet without exclusion!

Regardless of whether you read this whole page or not, if you have made or want to make your own website, please consider adding an accessibility extension to your browser that can check your site for a ton of accessibility concerns and give you detailed reports on the specific issues it finds!

The web 1.0(/early web 2.0) revival is really exciting, I love to see more people making their own personal space online where they have total control over what it looks and feels like, so I want to give people who may not have them the tools to make Accessible sites where everyone, regardless of ability, is enthusiastically included. The web is not only for abled people! I'm not perfect myself, but I do my best :o)

Thanks for reading the intro! Feel free to click away from the page now! :)

Table of Contents

Accessibility Resources

Disabled people use the internet! You may be one of us! Depending on disability/ability, there are tools we use to make navigating the internet more accessible to us, and there are also common ways that web developers forget (or simply don't know/care) to make navigating our sites possible for people, regardless of disability.

Keep the following in mind, and let these concerns help you plan and implement your designs.

Back to top ^

Semantic HTML & Screen Readers

A website should be navicable without being able to see it. This means that a screen reader should be able to read and understand the structure of your website via the structure of your HTML, not just what it visually looks like on the screen.

Usage of semantic HTML (an expanded feature of HTML5) is one way to achieve this accessibility. The following is a non-exhaustive list of some common best practices.

  1. <a href="/foo/bar.html">descriptive link text</a> (links/anchor tags) should be used to navigate to a different page than the one you are on (ex: a navigation bar at the top, or link to a different site), while <button onclick="onClickFunction()">Do something</button> should be used for functionality that exists on an individual page (ex: submitting a form, clicking to show spoiler text, toggling a setting, etc.)
    • There are exceptions to this of course. For example: you might have a button that both submits a form, and navigates the visitor to another page once that form is submitted successfully, but this is a good rule of thumb to keep in mind
  2. Your <h1>Header 1 Text</h1> header tags should follow a logical order. You can have two <h1>s in a row, but you shouldn't start with an <h4> then have an <h2> after it.
Back to top ^

Semantic HTML & Focus

Following semantic HTML guidelines wherever possible ensures not just that a screen reader can read the page and understand its structure, but also that functionality is preserved that allows visitors to navigate the page without using a mouse.

Have you ever filled out a form and used the tab key on your keyboard to navigate from one form field to the next? Do you typically navigate websites without using the mouse at all? It's common to use tab, among other keyboard keys, to navigate sites to some degree, even if you use a mouse most of the time. Some people (maybe even you!) don't use mice at all due to disability or preference. In conjunction with a screen reader, visitors should be able to navigate your site in a logical fashion even if they can't visually see it, and visitors should be able to visually see what element they have focused so that they know what they're interacting with even if there is no mouse cursor on the screen to indicate it.

This form of navigation is made possible in part by the focus property that all interactable HTML elements have. This property creates a visual signal around the element that is receiving focus that shows visitors which element on the page is currently selected. In the example of a form, you will often see a blue glow, or black and white border appear around whatever elmement has focus, however focus styles can also be customized.

Check the focus style by clicking on the input below, or using the tab key to move through the focusable elements on the page (and shift + tab to go backward) :o)

  1. Don't style one element to look like another wherever possible. For example: it's not uncommon to see developers style a <div> tag to look like a button. This happens because <div>s do not come with the default styling that <button>s do, therefore if you are trying to style it with CSS in such a way that it looks radically different to a normal button, it can be tempting to use a <div> instead. However this leads to serious accessibility issues that may prevent a user from being able to use that "button" at all, as divs are not inherently able to receive focus, meaning someone navigating the page without a mouse will not be able to interact with it.
  2. You can customize your focus styling by using the :focus CSS pseudo-class, but don't remove it, and make sure that what you change it to is visually distinct enough to be seen on all backgrounds on which it may appear (taking into account things like low vision, color blindness, etc.).
  3. If you haven't already, try navigating your website (or any website) with only the keyboard!
Back to top ^

ARIA

ARIA stands for Accessible Rich Internet Applications, and is simply a set of properties including labels and roles that can be added to HTML elements to make a website more accessible.

I'll be covering just a small selection of scenarios where ARIA properties may be used in a website. See the following examples:

  1. Let's say you have a link to another page, and you want that link to be an image: how do you tell a screen reader what the destination of that link is? If you do something like this: <a href="/ocs/room_full_of_raccoons.html"><img loading="lazy" src="/assets/layout/ocs_georgie_room.png"></a> the screen reader may not be able to glean any useful information, as it cannot describe the image, which has no alt text, and the link has no text. But! You can still make links out of non-text elements like images, icons, emoji, etc.! In this case you can either give the link a "title" property (a property used specifically by links) or you can give it an "aria-label" property, which can be used to describe many elements.

    Ok, so now it looks like this!
    <a href="/ocs/room_full_of_raccoons.html" aria-label="Georgie's Raccoon Room"><img loading="lazy" src="/assets/resources/ocs_georgie_room_01.png" alt="Crudely drawn button containing a cartoon raccoon face and the label 'Georgie's Raccoon room'"></a>
    Crudely drawn button containing a cartoon raccoon face and the label 'Georgie's Raccoon room'
    In this case you can use your discretion as to whether you want to use alt text on the image. I chose to do so because it tells you something about the link you might be clicking, but if it's just, say, a social media logo, and you think that the title/aria-label of the link covers it, you don't need to double up, as the screen reader will read both.