FreeCodeCamp: Applied Visual Design Accessibility
Walk-through and solutions. This article will walk you through freecodecamp.org “Applied Visual Design” challenges.
“Accessibility” generally means having web content and a user interface that can be understood, navigated, and interacted with by a broad audience. This includes people with visual, auditory, mobility, or cognitive disabilities. Websites should be open and accessible to everyone, regardless of a user’s abilities or resources. Some users rely on assistive technology such as a screen reader or voice recognition software. Other users may be able to navigate through a site only using a keyboard. Keeping the needs of various users in mind when developing your project can go a long way towards creating an open web. Here are three general concepts this section will explore throughout the following challenges:
- have well-organized code that uses appropriate markup
- ensure text alternatives exist for non-text and visual content
- create an easily-navigated page that’s keyboard-friendly
Having accessible web content is an ongoing challenge. A great resource for your projects going forward is the W3 Consortium’s Web Content Accessibility Guidelines (WCAG). They set the international standard for accessibility and provide a number of criteria you can use to check your work.— By FreeCodeCamp
You can also watch this video where I solve the Applied Accessibility Challenges.
💡It’s likely that you’ve seen an
alt attribute on an
img tag in other challenges.
Alt text describes the content of the image and provides a text-alternative for it. This helps in cases where the image fails to load or can't be seen by a user. It's also used by search engines to understand what an image contains to include it in search results. Here's an example:
<img src="importantLogo.jpeg" alt="Company logo">
People with visual impairments rely on screen readers to convert web content to an audio interface. They won’t get information if it’s only presented visually. For images, screen readers can access the
alt attribute and read its contents to deliver key information.
alt text provides the reader a brief description of the image. You should always include an
alt attribute on your image. Per HTML5 specification, this is now considered mandatory.
✅Solution →<img src=”doingKarateWow.jpeg” alt=”hello”>
💡In the last challenge, you learned that including an
alt attribute when using
img tags is mandatory. However, sometimes images are grouped with a caption already describing them, or are used for decoration only. In these cases
alt text may seem redundant or unnecessary.
In situations when an image is already explained with text content, or does not add meaning to a page, the
img still needs an
alt attribute, but it can be set to an empty string. Here's an example:
<img src="visualDecoration.jpeg" alt="">
Background images usually fall under the ‘decorative’ label as well. However, they are typically applied with CSS rules, and therefore not part of the markup screen readers process.
Note: For images with a caption, you may still want to include
alt text, since it helps search engines catalog the content of the image.
✅Solution →<img src=”samuraiSwords.jpeg” alt=””>
h6 elements) are workhorse tags that help provide structure and labeling to your content. Screen readers can be set to read only the headings on a page so the user gets a summary. This means it is important for the heading tags in your markup to have semantic meaning and relate to each other, not be picked merely for their size values.
Semantic meaning means that the tag you use around content indicates the type of information it contains.
If you were writing a paper with an introduction, a body, and a conclusion, it wouldn’t make much sense to put the conclusion as a subsection of the body in your outline. It should be its own section. Similarly, the heading tags in a webpage need to go in order and indicate the hierarchical relationships of your content.
Headings with equal (or higher) rank start new implied sections, headings with lower rank start subsections of the previous one.
As an example, a page with an
h2 element followed by several subsections labeled with
h4 tags would confuse a screen reader user. With six choices, it's tempting to use a tag because it looks better in a browser, but you can use CSS to edit the relative sizing.
<h2>Learn the Art of Living with Honor</h2>
<h3>How to Breathe Properly</h3>
<h3>How to Simplify your Life</h3>
💡HTML5 introduced a number of new elements that give developers more options while also incorporating accessibility features. These tags include
section, among others.
By default, a browser renders these elements similarly to the humble
div. However, using them where appropriate gives additional meaning in your markup. The tag name alone can indicate the type of information it contains, which adds semantic meaning to that content. Assistive technologies can access this information to provide better page summary or navigation options to their users.
main element is used to wrap (you guessed it) the main content, and there should be only one per page. It's meant to surround the information that's related to the central topic of your page. It's not meant to include items that repeat across pages, like navigation links or banners.
main tag also has an embedded landmark feature that assistive technology can use to quickly navigate to the main content. If you've ever seen a "Jump to Main Content" link at the top of a page, using a main tag automatically gives assistive devices that functionality.
article is another one of the new HTML5 elements that adds semantic meaning to your markup.
article is a sectioning element, and is used to wrap independent, self-contained content. The tag works well with blog entries, forum posts, or news articles.
Determining whether content can stand alone is usually a judgement call, but there are a couple simple tests you can use. Ask yourself if you removed all surrounding context, would that content still make sense? Similarly for text, would the content hold up if it were in an RSS feed?
Remember that folks using assistive technologies rely on organized, semantically meaningful markup to better understand your work.
section element is also new with HTML5, and has a slightly different semantic meaning than
article is for standalone content, and a
section is for grouping thematically related content. They can be used within each other, as needed. For example, if a book is the
article, then each chapter is a
section. When there's no relationship between groups of content, then use a
<h2>The Garfield Files: Lasagna as Training Fuel?</h2>
<p>The internet is littered with varying opinions on nutritional paradigms, from catnip paleo to hairball cleanses. But let’s turn our attention to an often overlooked fitness fuel, and examine the protein-carb-NOM trifecta that is lasagna…</p>
💡The next HTML5 element that adds semantic meaning and improves accessibility is the
header tag. It's used to wrap introductory information or navigation links for its parent tag and works well around content that's repeated at the top on multiple pages.
header shares the embedded landmark feature you saw with
main, allowing assistive technologies to quickly navigate to that content.
header is meant for use in the
body tag of your HTML document. This is different than the
head element, which contains the page's title, meta information, etc.
<h1>Training with Camper Cat</h1>
nav element is another HTML5 item with the embedded landmark feature for easy screen reader navigation. This tag is meant to wrap around the main navigation links in your page.
If there are repeated site links at the bottom of the page, it isn’t necessary to markup those with a
nav tag as well. Using a
footer (covered in the next challenge) is sufficient.
<li><a href=”#stealth”>Stealth & Agility</a></li>
💡 Similar to
footer element has a built-in landmark feature that allows assistive devices to quickly navigate to it. It's primarily used to contain copyright information or links to related documents that usually sit at the bottom of a page.
✅Solution → <footer>© 2018 Camper Cat</footer>
💡HTML5’s audio element gives semantic meaning when it wraps sound or audio stream content in your markup. Audio content also needs a text alternative to be accessible to people who are deaf or hard of hearing. This can be done with nearby text on the page or a link to a transcript.
audio tag supports the
controls attribute. This shows the browser default play, pause, and other controls, and supports keyboard functionality. This is a boolean attribute, meaning it doesn't need a value, its presence on the tag turns the setting on.
<source src=”https://s3.amazonaws.com/freecodecamp/screen-reader.mp3" type=”audio/mpeg” />
💡HTML5 introduced the
figure element, along with the related
figcaption. Used together, these items wrap a visual representation (like an image, diagram, or chart) along with its caption. This gives a two-fold accessibility boost by both semantically grouping related content, and providing a text alternative that explains the
For data visualizations like charts, the caption can be used to briefly note the trends or conclusions for users with visual impairments. Another challenge covers how to move a table version of the chart’s data off-screen (using CSS) for screen reader users.
<! — Stacked bar chart will go here →
<figcaption>Breakdown per week of time to spend training in stealth, combat, and weapons.</figcaption>
💡Improving accessibility with semantic HTML markup applies to using both appropriate tag names as well as attributes. The next several challenges cover some important scenarios using attributes in forms.
label tag wraps the text for a specific form control item, usually the name or label for a choice. This ties meaning to the item and makes the form more readable. The
for attribute on a
label tag explicitly associates that
label with the form control and is used by screen readers.
You learned about radio buttons and their labels in a lesson in the Basic HTML section. In that lesson, we wrapped the radio button input element inside a
label element along with the label text in order to make the text clickable. Another way to achieve this is by using the
for attribute as explained in this lesson.
✅Solution →<label for=”email”>Email:</label>
💡The next form topic covers accessibility of radio buttons. Each choice is given a
label with a
for attribute tying to the
id of the corresponding item as covered in the last challenge. Since radio buttons often come in a group where the user must choose one, there's a way to semantically show the choices are part of a set.
fieldset tag surrounds the entire grouping of radio buttons to achieve this. It often uses a
legend tag to provide a description for the grouping, which is read by screen readers for each choice in the
fieldset wrapper and
legend tag are not necessary when the choices are self-explanatory, like a gender selection. Using a
label with the
for attribute for each radio button is sufficient.
<legend>What level ninja are you?</legend>
<input id=”newbie” type=”radio” name=”levels” value=”newbie”>
<label for=”newbie”>Newbie Kitten</label><br>
<input id=”intermediate” type=”radio” name=”levels” value=”intermediate”>
<label for=”intermediate”>Developing Student</label><br>
<input id=”master” type=”radio” name=”levels” value=”master”>
💡Forms often include the
input field, which can be used to create several different form controls. The
type attribute on this element indicates what kind of input will be created.
You may have noticed the
submit input types in prior challenges, and HTML5 introduced an option to specify a
date field. Depending on browser support, a date picker shows up in the
input field when it's in focus, which makes filling in a form easier for all users.
For older browsers, the type will default to
text, so it helps to show users the expected date format in the label or as placeholder text just in case.
✅Solution → <input type=”date” id=”pickdate” name=”date”>
💡Continuing with the date theme, HTML5 also introduced the
time element along with a
datetime attribute to standardize times. This is an inline element that can wrap a date or time on a page. A valid format of that date is held by the
datetime attribute. This is the value accessed by assistive devices. It helps avoid confusion by stating a standardized version of a time, even if it's written in an informal or colloquial manner in the text.
Here’s an example:
<p>Master Camper Cat officiated the cage match between Goro and Scorpion <time datetime="2013-02-13">last Wednesday</time>, which ended in a draw.</p>
<p>Thank you to everyone for responding to Master Camper Cat’s survey. The best day to host the vaunted Mortal Kombat tournament is <time datetime=”2016–09–15">Thursday, September 15<sup>th</sup></time>. May the best ninja win!</p>
💡Have you noticed that all of the applied accessibility challenges so far haven’t used any CSS? This is to show the importance of a logical document outline, and using semantically meaningful tags around your content before introducing the visual design aspect.
However, CSS’s magic can also improve accessibility on your page when you want to visually hide content meant only for screen readers. This happens when information is in a visual format (like a chart), but screen reader users need an alternative presentation (like a table) to access the data. CSS is used to position the screen reader-only elements off the visual area of the browser window.
💡Low contrast between the foreground and background colors can make text difficult to read. Sufficient contrast improves the readability of your content, but what exactly does “sufficient” mean?
The Web Content Accessibility Guidelines (WCAG) recommend at least a 4.5 to 1 contrast ratio for normal text. The ratio is calculated by comparing the relative luminance values of two colors. This ranges from 1:1 for the same color, or no contrast, to 21:1 for white against black, the strongest contrast. There are many contrast checking tools available online that calculate this ratio for you.
💡Color is a large part of visual design, but its use introduces two accessibility issues. First, color alone should not be used as the only way to convey important information because screen reader users won’t see it. Second, foreground and background colors need sufficient contrast so colorblind users can distinguish them.
Previous challenges covered having text alternatives to address the first issue. The last challenge introduced contrast checking tools to help with the second. The WCAG-recommended contrast ratio of 4.5:1 applies for color use as well as gray-scale combinations.
Colorblind users have trouble distinguishing some colors from others — usually in hue but sometimes lightness as well. You may recall the contrast ratio is calculated using the relative luminance (or lightness) values of the foreground and background colors.
In practice, the 4.5:1 contrast ratio can be reached by shading (adding black to) the darker color and tinting (adding white to) the lighter color. Darker shades on the color wheel are considered to be shades of blues, violets, magentas, and reds, whereas lighter tinted colors are oranges, yellows, greens, and blue-greens.
color: hsl(0, 55%, 15%);
background-color: hsl(120, 25%, 55%);
💡There are various forms of colorblindness. These can range from a reduced sensitivity to a certain wavelength of light to the inability to see color at all. The most common form is a reduced sensitivity to detect greens.
For example, if two similar green colors are the foreground and background color of your content, a colorblind user may not be able to distinguish them. Close colors can be thought of as neighbors on the color wheel, and those combinations should be avoided when conveying important information.
Note: Some online color picking tools include visual simulations of how colors appear for different types of colorblindness. These are great resources in addition to online contrast checking calculators.
💡Screen reader users have different options for what type of content their device reads. This includes skipping to (or over) landmark elements, jumping to the main content, or getting a page summary from the headings. Another option is to only hear the links available on a page.
Screen readers do this by reading the link text, or what’s between the anchor (
a) tags. Having a list of "click here" or "read more" links isn't helpful. Instead, you should use brief but descriptive text within the
a tags to provide more meaning for these users.
✅Solution → <a href=””>information about batteries</a>
💡HTML offers the
accesskey attribute to specify a shortcut key to activate or bring focus to an element. This can make navigation more efficient for keyboard-only users.
HTML5 allows this attribute to be used on any element, but it’s particularly useful when it’s used with interactive ones. This includes links, buttons, and form controls.
<h2><a id=”first” href=”” accesskey=”g”>The Garfield Files: Lasagna as Training Fuel?</a></h2>
tabindex attribute has three distinct functions relating to an element's keyboard focus. When it's on a tag, it indicates that element can be focused on. The value (an integer that's positive, negative, or zero) determines the behavior.
Certain elements, such as links and form controls, automatically receive keyboard focus when a user tabs through a page. It’s in the same order as the elements come in the HTML source markup. This same functionality can be given to other elements, such as
p, by placing a
tabindex="0" attribute on them. Here's an example:
<div tabindex="0">I need keyboard focus!</div>
Note: A negative
tabindex value (typically -1) indicates that an element is focusable, but is not reachable by the keyboard. This method is generally used to bring focus to content programmatically (like when a
div used for a pop-up window is activated), and is beyond the scope of these challenges.
<p tabindex=”0">Instructions: Fill in ALL your information then click <b>Submit</b></p>
tabindex attribute also specifies the exact tab order of elements. This is achieved when the value of the attribute is set to a positive number of 1 or higher.
Setting a tabindex=”1" will bring keyboard focus to that element first. Then it cycles through the sequence of specified
tabindex values (2, 3, etc.), before moving to default and
It’s important to note that when the tab order is set this way, it overrides the default order (which uses the HTML source). This may confuse users who are expecting to start navigation from the top of the page. This technique may be necessary in some circumstances, but in terms of accessibility, take care before applying it.
<input tabindex=”1" type=”search” name=”search” id=”search”>
<input tabindex=”2" type=”submit” name=”submit” value=”Submit” id=”submit”>
Are you still here?! Well, if you are, congratulations! You just finished the “Applied Accessibility” by freecodecamp!
If you are interested for more freeCodeCamp challenges and solutions you can check the articles in my profile.
Disclaimer: Definitions, instructions and examples are by freeCodeCamp.org
Would you like to get me a coffee?!☕️
You can do that here → paypal.me/eleftheriabatsou
But If you can’t, that’s ok too 😍.