Accessibility (sometimes stylized as A11y) is the practice of making your websites able to be easily used by as many people as possible regardless of their physical and cognitive abilities or how they access the web. A quick rundown of the qualities of an accessible website are as follows:

• Websites should be able to be navigated via keyboard, mouse, touch screens, and assistive technologies such as screen readers like NVDA and JAWS or voice assistants like Siri or Alexa.
• Applications should be built from the ground up to be understandable and usable by anyone regardless of auditory, visual, physical, or cognitive abilities.
• Website design should also be mindful of the fact that features like rapid motion or poor contrast can cause headaches or even epileptic seizures, and avoid using these in ways that could cause harm.

Traditionally accessiblity is associated with a focus on helping people with disabilities, such as those who are blind or hard of hearing, which is plain and simple the right thing to do. Beyond that, however, the practice of making sites accessible actually benefits everyone:

• Semantic HTML improves both accessibility and SEO, which makes your website rank better in search engines like Google.
• Good practices that improve accessibility also make your site more usable by mobile phone users, those on slow networks, and those on low-end hardware.
• Providing accessible websites is actually part of the law in some countries. If you run a business, following these laws can also help you as it can open up markets that you otherwise would be unable to reach.

According to the World Health Organization, about 15% of the total world population has some form of disability. A key part of accessible design is thinking beyond how you access the web and considering how your end users will interact with what you create. The main types of disability to consider are explained below, along with any types of assistive technologies (abbreviated as ATs) that they use to access web content.

People with visual impairments include those with blindness, low-level vision, and color blindness. They often use the following ATs to access the web:

• Screen Magnifiers, either physical or digital (such as the built-in zoom capabilities of modern browsers and operating systems).
• Screen readers, which read digital text aloud. Some examples include:
  • Downloadable programs like JAWS ( ), NVDA ( ), and Orca ( ).
  • Built-in options like VoiceOver ( ) or TalkBack ( ).

People with hearing impairments include those with auditory impairments or deaf people, which means they have either low hearing levels or no hearing at all. While people with hearing impairments do use ATs, there are none designed specifically designed for computer use. However, you can utilize specific techniques such as Closed Captioning or text transcripts to make any audio and video content more accessible to them.

People with mobility impairments include those who have disabilities concerning movement. They might be purely physical issues (paralysis or loss of limb), might be a weakness or loss of control in limbs caused by neurological or genetic disorders, or may simply be less dexterous as a result of old age. The primary way you can accomodate these users is by improving keyboard navigation and allowing the page UI to be manipulated via keyboard input.

People with cognitive impairments covers a very wide range of end users. Examples include those with intellectual disabilities, those with learning disabilities, those with mental illnesses, and senior citizens facing challenges due to old age. Struggles they commonly face include difficulty with understanding content, trouble remembering how to complete tasks, and confusion caused by inconsistent page layouts.

The best way to accomodate these users are as follows:

• Making your content as easily understood as possible, such as using plain-language standards and delivering it in multiple ways.
• Focusing attention on important content while minimizing distractions such as advertisements.
• Keeping your website's layout and navigation consistent from page-to-page.
• Utilizing familiar styling of elements, such as underlined links, buttons with obvious backgrounds and borders, and standard text content structure utilizing headings/paragraphs/lists/etc.
• Breaking any instructions down into their most basic, essential steps and including progress indicators if deemed necessary.
• Making forms as easy as possible to complete by utilizing things like clear and concise labels and error messages.

Semantic Hypertext Markup Language (HTML) means using HTML elements for their intended purpose as much as possible. Non-semantic elements, such as <div> and <span>, are elements that tell you nothing about their content by the tag alone. Semantic elements are elements such as <main> and <nav> that clearly indicate their purpose via their tag name. While you can use CSS and Javascript to make any element behave like another (such as making a link act like a button), this often doesn't result in the most accessible websites.

• Creating page layouts utilizing the semantic elements added in HTML5, such as <main>, <nav>, <aside>, <article>, <header>, <footer>, etc. A full list of these elements along with instructions on their use can be found on W3Schools' Page on Semantic HTML Elements.
• Following a consistent content structure that utilizes headings, paragraphs, and lists. This allows screen readers to read through the content in the intended order, and in multiple chunks rather than as one huge chunk of text.
• Using semantic HTML5 elements for UI controls as much as possible. For example, if you need what is functionally a button, it's always better to use a <button> rather than a <div> styled to look like a button. If you have to use non-semantic UI elements, you should take the steps to improve accessibility by adding tabindex to elements that act as traditionally focusable elements and by adding the appropriate WAI-ARIA labels (covered in a later section).
• Using meaningful button and label text, using descriptive link text, and using a <label> for every form input. Good links and labels have text that makes sense both in and out of context. Inputs having <label> elements associated with them creates a clear connection between the input and the label, and makes it easier to select the input.
• When using tables, using the summary attribute or a matching <caption> element to give a quick summary to screen readers. Captions are generally better as they can be read by all users. It's also good practice to use the scope attribute to indicate whether a table header element (<th>) is for a row or a column.
• Including text alternatives for images and videos, be it through alt text, title attributes, or <caption> elements. Using empty alt attributes (alt="") for decorative images is a must as it will prevent screen readers from attempting to describe images that aren't essential for understanding the content.
• Including adequate spacing between large amounts of interactive content such as groups of buttons, links, etc.

• Using HTML <table> elements to create page layouts, which confuses screen readers and may render them unable to navigate the page properly.
• Not following any type of page content structure. Examples include manually typing out lists rather than using <ul>/<ol> elements, using linebreaks to create "paragraphs," and changing font sizes inline to create "headings." This results in web pages that are both hard to style with CSS and inaccessible to screen readers.
• Using non-semantic HTML5 elements for UI controls without adding accessibility through other means, such as using a link containing an empty anchor tag in conjunction with Javascript (javascript:void(0) and the onclick event) to simulate a button. Non-semantic elements are not keyboard focusable or labeled properly by default, which can break pages for keyboard navigation and screen readers. Using anchor links in combination with javascript:void(0) doesn't include the correct semantics for screen readers and can even easily break the page for all users.
• Using non-descriptive text for buttons like 'Click Me.' Using vague phrases like 'click here' for linked text. Not using <label> to label form inputs.
• Not providing text alternatives to images and videos. Worse yet, using image files containing text to display important text content.

HTML is accessible by default when used correctly, so web developers should strive to follow good semantics as much as possible.

CSS and JavaScript are able to help or damage accessibility depending on how they are used. When both are used properly in conjunction Semantic HTML, they can enhance the accessibility of your website.

Cascading Style Sheets (CSS) are very powerful as they are the backbone of visual design on the web; if the HTML is bones of the house, CSS is the wallpaper and the furniture. With CSS it's possible to make any HTML element look like another, which can either hurt or help your accessibility. Examples of Good Practices for CSS include:

• Sensible font sizes, line heights, letter spacing, etc. that result in legible text that's comfortable to read.
• Links, form elements, and other focusable elements should have distinct styling when focused.
• Semantic elements such as lists and interactive elements like buttons and links should look similar to what the average user will expect them to and should stand out from other elements on the page.
• Using colors for backgrounds, text, links, etc. that have appropriate contrast ratios. You can use WebAIM's Color Contrast Checker or the built-in developer tools of modern browsers to check the contrast of your colors.
• Avoid hiding crucial content with visibility: hidden or display: none unless you want to hide it from screen readers.

Here is one of my favorite examples of CSS being utilized to its fullest to increase accessibility. The following code is from Bootstrap, and is very helpful when designing with screen readers in mind:

Items with the class .sr-only are hidden off screen, and their contents will only ever be read out loud by screen readers. This is great for adding alternative text and labels for users of screen readers that you don't want visible in any way, shape, or form to other users.

Javascript is an incredibly powerful language that allows for the creation of robust apps. While not everything made with Javascript can be made accessible to 100% of users, it is good to strive towards making your web content (especially simple web pages) as accessible as possible.

The key to accessible Javascript comes in knowing how much Javascript is enough. Ask yourself: do you really need to use a framework for a simple one-page website? Thinking like this is called designing with unobtrusive JavaScript in mind, which conveys the idea that Javascript should be used to enhance basic functionality, not create it. Using Javascript to enhance the user's experience with things like form validation or custom keyboard-accessible controls for <video> or <audio> elements when browsers don't provide the functionality by default are great options for using Javascript in an accessible way.

WAI-ARIA stands for Web Accessibility Initiative - Accessible Rich Internet Applications, and is a specification written by the World Wide Web Consortium (W3C). It defines additional HTML attributes that can be applied to elements in order to improve accessibility by providing additional descriptive labels. WAI-ARIA attributes don't affect the way webpages look; the only thing they affect is the information exposed by the browser's accessibility APIs, which is what screen readers use to read text.

• Roles — these define what an element is or does. Many mirror semantic HTML5 (such as role="navigation" being equivalent to HTML5's <nav> tag), though there are other roles that represent common parts of page structures (such as role="search").
• Properties — These define properties of an element in order to give them extra meaning. Examples include using aria-required="true" to indicate that a form input is required, or using aria-labelledby="label" in order use the text within the element with the #label ID as a label for multiple other elements at once.
• States — A set of special type of properties that define the current conditions of an element, which can change dynamically via Javascript. One example is aria-disabled, which indicates whether an item is disabled or not by being set to true or false.

• To Label Landmarks, especially to go beyond HTML5 semantics by labeling UI elements such as search forms, tabs, and tabgroups.
• To Improve Keyboard Accessibility, which can be hampered by using Javascript with non-semantic elements. WAI-ARIA's tabindex can make elements that are normally non-focusable via the TAB key focusable.
• When Controls are Non-semantic, such as when complex UI elements like buttons are created using nested <div> elements rather than a single <button> element.
• For Dynamic content; screenreaders can be informed when content is updated dynamically via aria-live.
• Only when necessary! Using native HTML features like <main> and <nav> should always be done for accessibility, but in cases where you need to go beyond HTML or don't have full control of the code, WAI-ARIA can be utilized to make your page more accessible.

This page is even using WAI-ARIA attributes! The headers are not traditional heading tags due to project requirements, so accessibility is added by giving them the role="heading" attribute and specifying the heading level with the aria-level attribute. All decorative icons on this page are also using the aria-hidden="true" attribute, which is used to hide elements from screen readers that are unable or unecessary to be read by screen readers.

For further reading, you can learn WAI-ARIA basics on the MDN Web Docs or read the WAI-ARIA docs in full. You can also read about WAI-ARIA browser compatibility on "Can I Use", and about WAI-ARIA screenreader support on this WAI-ARIA Screen reader compatibility article by Powermapper.

The Web Content Accessibility Guidelines (WCAG) were developed through the W3C process in cooperation with individuals and organizations around the world. The goal of the WCAG is providing a single shared standard for web content accessibility that is able to meet the needs of individuals, organizations, and governments across the globe. The WCAG is divided into four main categories which specify how you can implement content in ways that are perceivable, operable, understandable, and robust.

The best way to start learning about the WCAG is via the WCAG at a Glance page on the WCAG website. It is not necessary to memorize the WCAG, but it's good to keep it in mind and use it as a reference when designing with accessibility in mind.

• All information was sourced from MDN's accessibility docs and the World Wide Web Consortium's WCAG.
• Some provided example code is from the HTML/CSS/JS framework Bootstrap.
• Made for FreeCodeCamp's Web Certification . Click here to view the Codepen mirror.