While the goal of this page is not to provide a comprehensive list of accessibility issues, it will provide a list of common problems you're likely to see along with fixes and suggested reading.

For a comprehensive guide to accessibility, visit WCAG 2.1. The County strives to achieve compliance with WCAG's AA guidelines.

ARIA landmark roles:
ARIA landmark roles help screen reader users identify regions of content, such as navigation bars, forms and search areas. This makes pages easier to browse for users with disabilities. Use regions where appropriate to identify sections of pages.
More reading:
Bold
Do not use <b>; if the phrase being highlighted requires semantic emphasis, use <strong>. If it is being boldfaced for decorative purposes, use CSS to style the text with a subclass.
More reading:
Color contrast
Text, backgrounds and other page elements must use sufficient contrast. Many factors play into the definition of "sufficient," including the colors used, font sizes, font effects, etc. This includes text used on images, such as banners, and text used over gradients (check the lowest contrast areas for sufficient contrast). Use WebAIM's contrast checker tool to select color combinations that meet all WCAG AA standards.
More reading:
Default language
Every page should have a default language, usually above the HTML head, as such: <html lang="en">. This tells screen reading software which language it should read back to its user. The HTML Language can also be changed on elements within a page when using translated or localized content.
More reading:
Documents/PDFs:
An accessible PDF must be machine readable and tagged properly – including reading order. Tags and proper reading order allow users of screen readers to easily browse and scan through a document in a similar fashion to sighted users. While the use of Adobe Acrobat Pro may be necessary for many of these requirements, properly setting up a document in applications like Microsoft Word can help ensure that a document is useful to users with disabilities.
More reading:
Focus indicators:
Focus indicators make it possible for keyboard users to understand which page elements they are interacting with. Page elements, such as form fields, links and buttons, should have visible focus indicators.
More reading:
Headings:

Headings create structure that allow users with disabilities to browse through a page and have semantic value. They should not be used to style text. For example, using an <h3> because you need a smaller heading is an accessibility violation. Every page should start with an <h1> and any <h2> headers should follow and <h1>. Any <h3> headers should follow and <h2> and so on. It's important to preserve this hierarchy to allow users to navigate pages. If larger or smaller headings are needed, use the appropriate heading as per the hierarchy and create a CSS sub-class to visually style the heading.
More reading:

IDs
Any IDs used in the development of a page must be unique (used only once on the page). When IDs are used more than once, unexpected inoperability of features may result.
More reading:
Iframes
When using iframes, always provide a title for the iframe.
More reading:
Image alt text
"Alt text" functions like a hidden caption that is read to users of screen readers who cannot otherwise see an image. These are necessary on any image that communicates information. Every image should have an alt attribute, however, if an image is purely decorative, such as a logo that is not linked, the alt may be left blank: alt=" ". When writing alternate text, it is not necessary to include a phrase such as "image of" because the screen reader will announce that the element is an image. A simple, brief caption that explains the context of the image will suffice.
More reading:
Inline styling
Do not use inline styling attributes on web pages. Users with disabilities may make use of locally stored custom style sheets to help them overcome visual impairments, such as color blindness. Elements that are styled on the page prevent users from using these accommodations. Always use CSS for styles.
More reading:
Italics
Do not use <i>; if the phrase being highlighted requires semantic emphasis, use <em>. If it is being italicized for decorative purposes, use CSS to style the text with a subclass.
More reading:
Labels

Whenever a page calls for input fields, such as a form, properly label the input fields with a <label> attribute. Do not use the placeholder attribute as a substitute for a <label>. Without proper input fields, users of screen readers will have no indication of how to interact with the field. In addition, every <form> requires a submit button, like so: <input type="submit">.
More reading:

Link styling
We often recognize links by their blue color but relying solely on color can cause problems for some users. Beyond color, links need an additional visual indicator to help users identify them. In most cases, the default underline, will suffice, but, in limited circumstances, other strategies can be used on navigation links, for example, such as background colors or larger fonts with higher contrast ratios.
More reading:
Link Text
As users tab through a page, screen reader software reads back the anchor text to the users. Because of this, it's important that link text is as accurate as possible. Do not use “click here” constructions or “http” links for anchor text. Instead, link a useful, helpful phrase. Example: Download the mayor's statement.
Links must also be unique; two links with identical anchor text is permissible only if they point to the same destination. However, two links with identical anchor text that point to two different destinations are an accessibility violation. Sometimes, this is difficult to avoid. For example, two “contact” links that point to different email accounts. In these instances, an ARIA label must be used to differentiate the non-unique links. Though the anchor text may still appear to read “Contact us,” in the browser, the ARIA labels on the links can will say “contact ITD” and “contact Miami-Dade County,” to the screen reader, resolving the violation.
More reading:
Page Titles
Each page needs a unique page title that reflects the page's specific content. Do not use generic page titles for a series of pages on a site since users of assistive technologies need these titles to differentiate pages as they, for example, switch tabs. Flow from most specificity to least. Example: Schedule a garbage pickup – Miami-Dade County. Page titles are meta information and are not to be confused with the headings that appear on web pages. Page titles are also an important SEO factor because page titles are shown on Google search pages. Because Google cuts off titles after 600 pixels, an ideal page title should fit into 50-60 characters.
More reading:
“Skip to main content” link
These hidden links are often the first thing you'll find if you hit “tab” on a freshly loaded page. They allow users of screen readers to skip past repetitive blocks of content, such as page navigation, and dive right into the actual page content. Without these links, users of screen readers would have to work through the navigation every time they load a page. Every page must have a “skip navigation” link. More reading:
Tables
Do not use tables for layout purposes. Tables should only be used to present data. When building tables, it's important to use <th> to identify cells that act as headers and <td> to contain the data corresponding to those table headers. Additionally, the use of the scope attribute is necessary to indicate to the screen reader how table data relates to headers.
More reading:
Underline
Do not use <u>; use text-decoration: underline; instead. Use sparingly because underlines may lead users to think the underlined text is a link.
More reading: