Creating Accessible Content

Print icon Print

Creating Accessible Content

Overview

Improving the accessibility of your website content will help provide a consistent experience for all users, including those who may browse sites using assistive technology such as:

The Mandate

Local Law 26 of 2016 mandates that the City of New York improve the accessibility of NYC.gov and agency websites.

The Requirements

Your agency is responsible for improving the accessibility of your website(s) and/content in order to meet the requirements of the Web Content Accessibility Guidelines (WCAG) 2.2 AA.

About This Page

The following info is designed to help you improve the accessibility of your web content and maintain your site(s) on NYC.gov through Interwoven TeamSite (the City's enterprise content management system) in accordance with the WCAG 2.2 AA guidelines.
Note: The information on this page is subject to change without notice.

Please only share this page with TeamSite users or web content creators at your agency, and ensure that this site or this page does not get linked to from anywhere, publicly.

For Questions...

If you need our assistance with posting accessible content to your site, please prep your content in accordance with the guidelines below first, then send it to Webmail. If you don't know how to send your content to Webmail, please email your questions to the NYC.gov Web Operations team.

Web Accessibility Resources

Content Types/Items/Issues

The primary destinction between the "regular" and "custom/special" content below is that we estimate it may take longer to mitigate the issues related to "custom/special" content.

Regular Content

Custom/Special Content

Color Contrast for Text and Images

Requirement

Text and images of text must have a contrast ratio of at least 4.5:1 against the background that each appears on.
Note: Colors that are 4.5:1 (or very close to it) usually work on both light and dark backgrounds.

Related WCAG 2.2 Guideline

Instructions/Comments

Use an accessibility evaluation tool to identify color contrast issues on your web pages. Rectify the issues and retest. Automated contrast calculators cannot always understand the context of elements and will occasionally report incorrect values, usually due to being incorrect about the background color. Inspect errors to see that the correct colors went into the calculator.

Resources

Back to Content Type List

Link Color

Requirement

Color should not be the only way of distinguishing links. Links on agency sites on NYC.gov must also be bold. Links within the body content area of pages on agency sites on NYC.gov will be underlined.

Related WCAG 2.2 Guideline

Instructions/Comments

Review your website to ensure that links throughout it are a different color than the regular body content and also bold. (Links on the home page should be bold as well.) If desired or necessary, links on your site can also be underlined.

Resources

Examples

Back to Content Type List

All Caps

Best Practice

Except when used in abbreviations and acronyms, avoid formatting text in ALL CAPS.

Instructions/Comments

Review your website content and change text styled in ALL CAPS text to regular case or title case, as appropriate. People recognize words by their shapes, so avoiding the use of ALL CAPS makes words easier to recognize, which improves the speed at which users will perceive and understand your web content.

Resources

Back to Content Type List

Bold or Italicized Text

Best Practice

Minimize the use of bold or italicized text.

Instructions/Comments

Bold (i.e., <b>) and italics (i.e., <i>) tags are often used to style content or to stress content's importance. However, in general, users find large blocks of bold or italicized text hard to read, so avoid those styles whenever possible. Also, from an accessibility standpoint, some screen readers do not recognize those tags. It is a known issue that TeamSite's visual editor (TinyMCE) still uses the <b> and <i> tags; the Interwoven team is investigating a solution to replace them with the <strong> and <em> tags, respectively.

Resources

  • WebAim Fonts (Refer to item 7 in the "Important" box, and to the font variations sections)

Back to Content Type List

Colored Text

Requirements

  1. Avoid using large blocks of colored text in your web content.
  2. If you use color to emphasize something important, include another element such as an asterisk to identify it.
  3. If colored text is used, the contrast ratio between it and the background color that it appears on must be at least 4.5:1.

Related WCAG 2.2 Guideline

Instructions/Comments

Screen readers do not recognize colored text, and color blind individuals may not be able to differentiate some colors. Review the content on your site for colored text. If the colored text is used to emphasize something important, add an additional element, such as asterisks, surrounding it.

Red and/or green are often used to emphasize important text. Change red text, which is set in the commonly-used hex #ff0000 to hex #df0000, which provides sufficient contrast when on a white background.

Resources

Back to Content Type List

Acronyms/Abbreviations

Best Practices

  1. Spell out the full term and enclose the acronym in parentheses for the first instance on the page. When the full term appears before the acronym/abbreviation, you do not need to include a <abbr> tag.
  2. Use <abbr> tags for uncommon abbreviations/acronyms.
  3. If an uncommon term appears multiple times on a page, then use the <abbr> tag only in the first instance.

Instructions/Comments

For common, easily understood terms (e.g., St., Ave., Dr., US., etc.), you do not need to use the <abbr> tags.

Resources

Example

Back to Content Type List

Page Titles ("Browser Titles")

Requirement

Each web page must have a unique, short, descriptive title that describes the topic or purpose. On NYC.gov agency sites, we commonly referred these page titles as "browser titles." This is the title that appears when you hover over the browser tab.

Related WCAG 2.2 Guideline

Instructions/Comments

Review each page title to ensure that it is unique, describes the content of the page, and is in the standard format (e.g., "About NYCHA - NYCHA") established for pages on NYC.gov.

To review a page title in Chrome, for example, hover over the tab area of the browser window. To add or revise a page title in TeamSite, go to "File > Page Settings > Title," and select "Edit". Insert a title and/or revise the existing title. Set it in this format: "Page Name - Agency Site/Initiative Acronym or Name".

  • Ensure that each page title matches the page name used in the navigation. Doing so will provide for a better user experience on your site, and an expected experience across NYC.gov.
  • Insert "space hyphen space" in between the terms to be in line with the format used across NYC.gov.
  • Abbreviate the page title to three or four words when a page has a long name. But still ensure the page name is unique and follows the format listed above.

Resources

Example

Back to Content Type List

Headings & Sub-Headings

Requirements

  1. Use headings and sub-headings to visually convey relationships of content within a page in a logical and understandable sequence.
  2. Set the first heading within the body content area of a page as an h1 heading.
  3. Nest headings/sub-headings hierarchically (i.e., h1, h2, h3, etc.).
  4. Restrict headings and sub-headings to only a few words, when possible. (In general, you should not set full sentences as headings.)

Related WCAG 2.2 Guidelines

Instructions/Comments

Review each page on your site. Within the body content area, set the first heading as an h1, and set sub-sections with subsequent headings tags (e.g., h2, h3, h4, etc.,), hierarchically.

  • Since the h1 heading at the top of the body content area will represent the main heading for the page, logically, there should not be any other h1 headings within the page.
  • There can be multiple h2, h3, h4, etc. tags, but they must nest hierarchically.
  • Ensure no <b></b> or <strong></strong>tags appear within heading tags.
  • Do not "create" a heading by making the font size bigger and bolding the text. Screen readers cannot read such styling. Use the heading styles provided by the template.

Resources

Example

Back to Content Type List

Descriptive Link Text

Requirement

Link text must be descriptive, not generic/vague (e.g., click here, learn more, read more, etc.), and unique within the context of the content on the page.

Related WCAG 2.2 Guideline

Instructions/Comments

Review the text of each link on your site, and revise it to describe what will happen when the user clicks it (e.g., "Download the 5.2.17 agenda," "Visit the HPD website," "Learn more about ID.NYC,"). Avoid non-descriptive link text such as "Read more," "Learn more," "Click here," etc.

Resources

Examples

Back to Content Type List

Consistent Identification of Links and Functional Items

Requirement

Components that have the same functionality or links that point to the same location are labelled consistently across web pages/instances.

Related WCAG 2.2 Guideline

Instructions/Comments

Use consistency when labelling links and functionality across pages. For example, if there is link text of "2017 Annual Report" on one page that links to the "2017_annual-report.pdf," use the same link text if you link to it on other pages.

Resources

Back to Content Type List

Content or Links in Other Languages

Requirements

  • Set content and links in other languages with lang attributes.
  • Have the text of links in other languages translated into those languages.

Related WCAG 2.2 Guideline

Instructions/Comments

  • Include html code lang="xx" where "xx" equals the ISO code of that language to links and content in other languages.
  • Note: The NYC.gov templates will be updated to specify that the page language for each page on NYC.gov is English. On pages where the content is in another language, you must include lang attributes.

Resources

Back to Content Type List

Hero Content

Requirements

  1. Set the hero so it does not autoplay (i.e., to advance to the next panel automatically).
  2. Set hero brief descriptions and side bar text in regular case.

Related WCAG 2.2 Guidelines

Instructions/Comments

If you need assistance turning off the hero autoplay feature, contact us. In some hero configurations, the brief descriptions that appear below the hero title will display in ALL CAPS. In TeamSite, however, be sure to set them in title case or regular case. We will be editing the template to make it display in regular case in the future. Hero content must also meet the other requirements on this page, particularly those related to non-text elements (e.g., include alt text, etc.). If a hero image functions as a link, describe that functionality in the alt text.

Resources

Back to Content Type List

Non-Text Elements (Text Alternatives, a.k.a. "Alt Text")

Requirements

  1. Provide text alternatives ("alt text") for all non-text elements (e.g., images, maps, image maps, infographics, logos, etc.). The "alt text" should communicate the same information as non-text elements.
  2. If a non-text element contains an image of text, include that text in the alt text associated with it and/or in the body content surrounding it.

Related WCAG 2.2 Guideline

Instructions/Comments

Non-text elements include images, graphics, logos, pictures, audio, video, infographics, buttons, icons, form controls, maps, image maps, interactive elements, etc. Purely decorative non-text elements do not require alt text, and should be presented in a way (i.e., aria-hidden) that will enable them to be ignored by screen readers and other assistive technology.

Review each non-text element on your site:

  • In the text surrounding it (e.g., body content or caption) and within alt text (alt tag) include a description of what the element is.
  • In general, avoid including text in images. If text, especially important text (i.e., deadlines, due dates, etc.) that appears in an image/infographic within the body content or caption and/or within alt text.

When drafting alt text:

  • Consider who is in the picture, where it was taken, and what the subjects of the photos are doing.
  • Limit alt text to 100 characters or less, including spaces.
  • Alt text should not be redundant to headings or links that it appears next to.
  • Alt text should describe what is in the image (e.g., "NYC Nonprofits logo," "Family in the park," etc.)
  • If you include an acronym in the alt text, precede the acronym by the full name of the entity, enclose the acronym in parentheses and insert a space between the letters of the acronym. For example, "Mayor's Office for People with Disabilities (M O P D.)"
  • For images that function as buttons or links, it is more important to describe the functionality in the alt text.
  • Do not include the words "Image of" or "Photo of" in the alt text.

Resources

Examples

  • Review this example image code to see how alt text (tags) are included: <img alt="Cover of Annual Report 2015" src="/assets/opportunity/images/content/pages/2015_ceo_annual_report.png">
  • Check out the NYC Human Resources Administration (HRA) Locations page to see how the text surrounding an embedded Google map explains that a map follows, and instructs users and screen reader users on how to access text listings of the HRA center locations (e.g., SNAP Centers example).

Back to Content Type List

Audio-Only or Video-Only (Prerecorded)

Requirements

  • Accompany audio-only content with text transcripts of the sounds, music, and dialogue.
  • Accompany video-only content with an audio description or a text transcript that explains the visual elements (e.g., the setting, who the significant characters are, what they are doing, and any text or logos that appear on the screen).

Related WCAG 2.2 Guideline

Instructions/Comments

Audio-only content is not accessible to deaf/hard of hearing individuals. Video-only content is not accessible to blind/low vision individuals. Have text transcripts created for the audio-only content and post them with that content. Have audio descriptions or text transcripts created for video-only content and post them with that content. For more information about creating transcripts and/or audio-descriptions, contact the City's Digital Accessibility Coordinator and/or the Mayor's Office for People with Disabilities.

Resources

Back to Content Type List

Videos/Multimedia (Prerecorded)

Requirements

  • Include synchronized captioning, either open or closed, in videos with audio.
  • Link to a text transcript.
  • Create an audio-described version of the video and include a link to it or include an audio description of the video in the page content before it.
  • Embed the video as a YouTube video or in an HTML 5 player. (Video controls must be accessible throughout the playback of the video.)
  • Include links to each multimedia element (e.g., "Watch the housing video," "Download the text transcript of the housing video," "Download the audio-described version of the housing video," "Listen to the audio of the housing meeting," etc.), aside from the embedded video.
  • Make sure the video does not autoplay when the page loads.

Related WCAG 2.2 Guidelines

Instructions/Comments

Deaf/hard of hearing individuals cannot hear the audio/dialogue and need captions or a text transcript of the sounds, music, and dialogue to understand what is happening in the video. Blind/low vision individuals cannot see any text, scene transitions, or any visual actions happening onscreen. They would need an audio description or text transcript that explains the important visual elements of the video (e.g., the setting, who the significant characters are, what they are doing, and any text and logos that appear onscreen).

Back to Content Type List

Expand/Collapse Items

Requirement

Adhere as close as possible to the NYC.gov Expand/Collapse Standards when building such content on your site. The content within the expand/collapse items must adhere to the other requirements outlined on this page.

Related WCAG 2.2 Guidelines

Instructions/Comments

Expand/collapse functionality is recommended for frequently asked questions or topics followed by lengthy explanations.

Resources

Back to Content Type List

Forms

Requirements

  • Adhere as close as possible to the NYC.gov Form Standards when building forms on NYC.gov.
  • Create and implement unique error messages for each required field. Error messages will display if a user does not complete a required field or submits invalid content for a required field.

Related WCAG 2.2 Guideline

Instructions/Comments

Follow these guidelines for forms on your site:

  • Ensure new forms built on NYC.gov follow the NYC.gov Form Standards.
  • Log unique error messages for each required field in a copy of the error message template. Each error message should be unique to the required field it is associated with. The first sentence of the error message should explain the error, and will appear bold. The second sentence of the error message should explain how to fix the error. Wrap the second sentence in span tags to ensure that it will appear unbold.
  • View a sample form. Click the submit button to view the unique error messages for each required field. (Notice that only the first sentence of the error message is bold.)
  • Review all existing forms on your agency site, and reach out to us to have them converted to the new (Fall 2017) form-related HTML and CSS, which takes into account these accessibility requirements.

Resources

Back to Content Type List

Tables

Requirement

Tables must contain only tabular data and be programmed correctly, and adhere to NYC.gov Table Standards. Tables on NYC.gov must also be responsive, meaning the layout responds to the user's device.

Related WCAG 2.2 Guideline

Instructions/Comments

Review each table to ensure that it contains only tabular data and that it is programmed correctly. Code your tables following the examples on our Tables page.

Resources

Back to Content Type List

"Back to Top" Links

Best Practice

Do not enclose "back to top" link in brackets (e.g., [back to top]).

Instructions/Comments

Brackets around "back to top" links will be read by screen readers, and add unnessary complexity for users. Since they are not necessary, remove all brackets, if any, surrounding "back to top links" on your site.

Back to Content Type List