Quick and Easy Accessibility (And Why It Matters)

Neocities’s founding has bred a whole new generation of web developers focusing on the creative side of the world wide web. This is wonderful, and I’m glad to be a part of it. I’d like to help these burgeoning developers sidestep the caveats of that early web look we so seek to simulate. In this text, I will to stress the importance of accessibility in your design, whatever that design may be. It’s a less difficult prospect than you might be worrying. If you’re new to web development, or simply not aware of how the platform has changed over the years, this document is for you. This will be a partially informative, partially historical document intended to help teach newer developers on best practices for accessibility in web design.

When designing for the web, it's important to remember the basis for HTML: it is a markup language. It's right there in the title.^[1] A markup language is a method of document formatting in computing where you literally type the formatting of the text as you type it. Everything from paragraphs to bulleted lists to tables is defined in HTML and it is up to the person formatting the document to "mark up" his text properly so it can be read.

See, the initial design of the world wide Web was basically just to let anyone host their own content of an interlinked spider web of a library, so each HTML file is a document in your own personal library. Or the library of the company or government hosting your content. Facebook was never considered in the original idea.

Now when you read a document, you read it from top to bottom. This is how HTML is design. Each HTML document is parsed starting from the top, and the individual HTML elements tell the browser what that kind of text is. Be it a heading, a paragraph, a list, a table, an image, a form, a button, computer code, preformatted text, you get the picture. There's an HTML element for all of that. This is commonly referred to as HTML semantics. The upshot to this is that an HTML document told the browser how it was read, and then the duty was on the browser to display that in a way that was appealing to the user. Since the primary method of communicating with the web is text, it's no surprise that HTML is easily presented as rich text on a screen, but what about those people who use a computer without vision?

Yes, there are blind people using computers. They tend to use screen readers, a form of software that audibly communicates what is presented on screen, usually with a text to speech program.^[2] Web browsers were expected to expose to the screen reader the purpose and design of each element on a page. So when the web was made available for browsing by everyone, those who used screen readers could rest easy knowing their computers were capable of reading the text of an HTML document. All the reader had to do was read the text and paragraphs, marking out any important headings, images, tables, and hyperlinks to their user.^[3]

Of course, as earlier stated, the web is primarily designed by the sighted, and the sighted have a very big advantage when it comes to reading text. So when journalists and the like began to adopt the web as their platform of choice for expressing ideas, they began to ask formatting questions: "Can we have an image that floats to the right like in our newspapers?" and so <img align="right"> was introduced. "Can we make ordered lists that don't use 1, 2, and 3?" and so <ol type="a"> was introduced, and it kept going from there. Page background colors? Sure! Image border size? Why not! Of course, surely you notice the trend: These attributes don't define what the text is, like HTML tags. Instead, they define how the text is presented. While not necessarily a bad thing, this helped set an incorrect precedent that what one saw on their web browser was the correct way that it should always look, and if your browser didn’t display the web page like that then it was wrong.^[4]

This information was often more than superfluous to our screen reader brethren, and began to cause problems when people began to "see" their HTML was right without realizing that the tearing of hair out they just did to make it "look" good have made their text otherwise unreadable as a document. Oh sure, that image looks neat when you put it in a table, floated it to the left, and placed it at the beginning of your content section, but when someone goes in there with a screen reader and tries to follow along they’ll be woefully confused after going through "Table, column two, row one, ‘He’s a fat cat, for sure’, five columns and twenty rows remaining."

This method of polluting the markup with visual information prompted the creation of CSS^[5] which, along with a widespread awareness campaign, helped make the concept of web accessibility a more widely understood prospect. CSS is great because it successfully introduced a schism between a document’s contents and a document’s appearance. When you think about your web page, think of it in those terms:

• HTML is what your site says.
• CSS is what your site looks like.
• JS is what your site does.

If your web page is completely unreadable if you take all the visual information away, you’re writing your HTML completely wrong.

While we aren’t completely free of providing visual information within the markup itself (see: the class attribute) the amount of it is much more acceptable and syntactically acceptable compared to the hell we went through before. The web has grown and changed since that point, and HTML is no longer purely a markup language, as JavaScript has caused it to evolve into the DOM, a breathing document that can be static or dynamic as we so choose. The web is still the ultimate canvas for the creator, but it is up to you to help people understand what you’ve painted.

As I am a sighted person, you might wonder what my stake in the accessibility game is. It’s a little selfish: I tend to listen to articles like this one using screen readers so I can do other activities (cleaning and driving, primarily) while "reading" the web. Many websites that deal in articles tend to be very well designed for accessibility, but some of my favorite websites are accessibility minefields. Spend some time trying to peruse a TV Tropes article with a screen reader and you’ll want to go deaf after the first 3 hyperlinks. For bonus points, go to the All Blue Article page.^[6]

But my enjoyment of listening to web articles is a byproduct of intelligent and accessible web design, and plenty of people benefit when you write an accessible web page. Many people on mobile devices are familiar with a "reading mode" that can appear on a properly formatted page. This mode strips superfluous information, most notably hiding ads and allowing variable text sizes, allowing the content to shine through. This mode becomes enabled on pages with a proper document outline - something that makes a page easier to read by itself.

Search engines use accessibility to provide useful information on web pages. Google’s famous image search capability initially used image alt text and nearby text found in the page content to determine the contents of an image, which worked phenomenally. And for those people so desperately clamoring for Search Engine Optimization, accessible sites help tell search engines exactly what your site is about, especially if you get people to link back to you with proper descriptions.

If your server has a content delivery network outage or a stylesheet or script fails to load, an accessible site will still be readable: all the text is still there! When I was in school our systems administrator failed to block subdomains of Wikipedia, only the main domain. The result was although we had no images or articles to peruse, we could still use Wikipedia as a jumping-off point for research or to validate information during arguments with classmates.

The advent of "bot" accounts on internet chat programs and social media services have ushered in a new era of site scraping for those sites that do not provide an API to access data. If your site is designed to be accessible, a scraper can easily sift through your document and find the necessary information as fast as it could a normal text file.

Recently I dropped a cell phone into a full sink, which shorted out the backlight. The phone still worked, and I needed to use it to keep in contact with my work and family. I was dismayed at how many Android designs completely fell apart when used with TalkBack (looking at you, Discord.) Otherwise, I was capable of accessing the entire phone despite not being able to see what I was touching at all.

When you write to be accessible, you explain, preserve, and future proof your perfect design for the entire world to view, rather than just providing a handrail for the handicapped.

What’s great about writing HTML is that it is, once again, a markup language. You literally explain what you’re typing as you’re typing it. Essentially it’s like a word processor document, and the tags and attributes are just longform for all the formatting you do by traversing the labyrinthine menus of a traditional word processor. If you know the specific accessible tags and attributes, you can type as you go and redesign as you need.

When you learn the available tools, you start to simply type the accessible information in as you go when it becomes second nature to you. It’s like pressing enter at the end of a line on a typewriter or ctrl+s to save your document: You know you should do it and you do it without thinking.

Accessible Text

If you’re writing a paper like this, each individual paragraph can be contained within individual paragraph tags, and their spacing can be manipulated entirely with CSS. It’s much easier to type than having to manually space things out with break tags and doesn’t pollute your markup when you need to go back and decide what exactly you want it all to look like. Additionally, you can benefit from having a single unified rule in your stylesheet for all paragraphs: unified CSS rules take up less bandwidth, get cached by the browser, and since your style is all in one place you don’t have to sift through your article micromanaging individual spacing for all your lines. Individual paragraphs can be manipulated through either the class attribute or the style attribute, depending on which suits your needs more.

HTML provides 6 heading tags in descending order of importance from H1 to H6, which help to outline your document. The aforementioned reader mode looks for block sections of a web page with a heading followed by around 2000 characters worth of text, so it’s a good idea to use them. Additionally, headers can be given IDs which can then be linked to by appending a URI with #ID-name.

There are additional tags for other semantic information (sections for the HTML5 outline spec, header to define areas introducing content to the user, etc.) A comprehensive list of elements and their semantic information is available at this MDN article.

This is all stuff you probably already know (or at least should know.) Let’s move on to the areas that stump and confound people when they complain about accessibility.

Accessible Images

When providing images through the >img< tag, it is important to provide an alt attribute. Alt stands for alternative. It is a text attribute that will be displayed to the user if the image cannot be displayed for whatever reason. The HTML standard previously mandated that all images required an alt attribute, but that has since been changed to merely a very strong recommendation.

Examples of reasons why an image would not be displayed to a user:

• A user is using a screen reader, and literally cannot see the image, so he must hear the alt text for that image in its stead.
• An image has failed to load, and the browser will place the alt text inside the image’s block instead.
• A user is using a text-only browser which cannot display images. The alt text will be displayed instead.
• A user is not a person at all but a bot or program that cannot process images. It will read the alt text instead.
• The file type being displayed is not supported by the user’s browser (SVG, WebP, JPG-2000, TIFF, etc). The image will not be displayed and alt text will appear in its place.
• A user has elected to have their browser not download images to save bandwidth, ram, cache, or hard disk space. The alt text will be displayed instead.
• A user has downloaded your document with wget or a similar program, and is viewing the page without embedded content.

It is important to note that alt text is never displayed to a user if the image loaded successfully and is being presented to the user visually. Alt text is not a caption, punchline, or postscript for your image. There is a large misconception about alt text and its role due to an improper implementation of it in early versions of Internet Explorer. This browser would display a tooltip balloon featuring the alt text when a user hovered over the image. As a result, sighted people who could "see" the image would use alt text to include a humorous caption to their image, since as we learned earlier, sighted people tend to "see" things as right and assume they are. This is where you get the term "alt text" in regards to things like xkcd’s mouseover text. In reality, this content would be better suited to the title attribute, which contains "advisory text" in regards to an element and can be included on any element. An even better example would be to include the text in a separate figcaption element, which provides exactly that: a caption to be included with a figure or image. We’ll go into further detail later

It’s important to consider the context of an image when including alt text. Alt text should not always be a direct description of an image. Sometimes all alt text needs to be is a transcription of the text in the image and nothing more, and sometimes it just needs to provide an explanation for the purpose of an image or icon.

For example: a wordmark of the Coca-Cola logo being used in the heading to a page usually needs only the alt text "Coca-Cola", since that is all the wordmark conveys. It does not need to say "The Coca-Cola wordmark, which uses wavy typographic ligature and red text" unless the purpose of the image is to show the style featured in the Coca-Cola wordmark (though that wouldn’t be featured in the header in such an instance.)

An icon of an envelope with an @ on it with a hyperlink to a user’s email address could simply have the alt text "email." An inverted triangle next to content that could be expanded to show more information by clicking on it can have the alt text "Expand" or "View more."^[7]

Images providing full text content would most likely just include a transcription of what is on the image. For example, if you included this "Under Construction" image on your website the alt text would simply be "This web is still being woven. Please don’t be surprised if it changes slightly from time to time..."

Images that are provided as an example in and of themselves can get away with providing alt text that just describes the image directly. For example, an image of tree rings nearby the content "The problems this tree focused are readily apparent. The blackened areas show when the tree was ravaged by a forest fire..." can have the alt text "A photo of a tree stump, showing the rings. Areas of interest: (1) Near the top of the image is a charred spot. (2) Closer to the center there is a close group of several rings…" and so on. There is no limit to how long alt text can be, though if they’re getting very unwieldy, you might consider using image maps, the picture element, or the object element to provide the alternative text as standard HTML. We’ll go into more detail about this in the next section.

If an image is purely intended for decoration, it is recommended you append that image using CSS. This is much easier with CSS3 since you can add pseudo-elements with ::before and ::after and style them entirely. An alternative suggested by the W3C is to provide an alt text that consists solely of an empty string: alt="". If you absolutely must include decorative images as an img tag, this is the way to do it. It is also noteworthy to mention that providing no alt text at all will simply read out the image’s URL to the user, which is very very undesirably, but can help if you want only to inform users that an image is there, like if you describe an image in the following paragraph or something.