What developers should take into consideration when writing code.
Testing
Adding Tables
Add "summary
" to table tag. A summary conveys information about the organization of the data in a table and helps users navigate it.
Add "scope
" to tables with headers. The scope
attribute can be set to row
or col
to denote that a header applies to the entire row or column, respectively.
Add "captions
". A caption functions like a heading for a table. Most screen readers announce the content of captions.
Adding SVGs
If it is used as an img
, must add title
attribute to it.
If svg
is use as a button, must add a tabindex
attribute
iFrames
iFrames needs to have a title
attribute
images vs background images
Images must have an alt
attribute
Images can also have a title
attribute
If an image gives a better understanding or context to a content, that images should not be a background image but an actual image.
Summary
Developers can emulate links with other elements, such as <div>
or <span>
elements and JavaScript click listeners. But, these kinds of emulated links need care. Developers wishing to emulate links must include the following:
Add tabindex=”0”
so that the link becomes keyboard focusable
Add role=”link”
so that assistive technology recognizes the element as a link
Add the styling cursor: pointer so that mouse users will recognize the element as a link.
Same applies to html elements used as buttons instead of the actual <button>
or <input>
element.
For example, the markup for an accessible emulated link might look like the following:
To avoid needing to implement the above, developers should prefer to use the <a>
tag instead.
What is css :focus and :focus-within
? How do you know when to use them? Read more about how to use :focus
here.
Note: If using role="button" instead of the semantic <button>
or <input type="button">
elements, you will need to make the element focusable and have to define event handlers for click
and keydown
events, including the Enter and Space keys, in order to process the user's input. See the official WAI-ARIA example code.
Remember that most browser will automatically validate correctly written HTML for you. Keep them simple with less layers of html tags wrapping them endlessly.
Web accessibility means that websites, tools, and technologies are designed and developed so that people with disabilities can use them.
What to look for
Keyboard focus
on focusable elements
Tab order
Label tags
Title attributes
Keyboard access
All "clickable" elements must be keyboard accessible
Likewise all hover/focusable elements must have alternate keyboard focus matching the mouse hover
Colors and fonts
Text colors should be tested for contrast. Make sure there is good color contrast between the text and the background
A recommended minimum font size is 16 px. Use bold to add emphasis rather than italics or UPPERCASE, but use it sparingly!
Images vs background images
Use background images only if necessary
All images must have an alt tag
Actual images must be use if it gives content more meaning or is the only content.
HTML Structure
Content will be read from left to right, therefore html should be written out the way the keyboard will tab through content
Input elements should have labels. They can hidden if not part of the design, but needs to be there for screen readers
All HTML should have proper aria
attributes
Lists should have the proper role
attribute
Titles, captions, and summaries
Iframes should always have a title to explain the content of the iframe
Tables must have summaries
explaining the content of the table and Captions
foe really large tables.
Images should always have meaningful titles for screen readers to read
Anchor tags <a>...</a>
should always have a title
Links and buttons
A link should always be a link and not a placeholder
Buttons
Miscellaneous
See boston.gov/digital for a lot of historical write ups on this work.
Write up on accessibility and text to speech completed for Jeniffer Vivar Wong/Office of Language and Communications Access on 4/5/21: https://docs.google.com/document/d/1aa9wCaG3AzPsh6pPC-padNOv4YgazwyUs2VkWglvSHA/edit
Potential ideas we found/brainstormed while writing this:
Tools/things Reilly found via Googling:
https://www.techradar.com/best/best-text-to-speech-software
Things Digital could consider:
Bringing back the ‘accessibility’ header. Can’t remember if it ever got built and we just turned it off but there are designs for it
Drupal modules for text to speech - would need devs to advise
Would want to do some market research with other govs or places before implementing
Lots of reference to Google cloud text to speech or Amazon Polly - unsure if this would be included in free license or we’d need to pay
General Assembly project for general user experience/desire of this or the City spending some money and hiring a consultant for this or a USDR volunteer
Updating boston.gov Drupal website with accessibility in mind. When adding content by editing/adding html elements, what they need to keep in mind for screen readers and people with disability.
Adding Images
When adding images to content, must add caption
and/or title
and/or alt
tags. This is especially important because screen readers reads them.
The editor we are using "ckeditor" provides at least one field to enter either a caption, title, or alt tags. If all three fields are provided please enter content for all three fields.
Please see the "How guide" section on the best ways to add and edit an image.
Adding Tables
Tables summaries must be added to each table created. Editors can use "ckeditor" to add summaries to each table. The summary
must explain exactly what the table content is about.
See the "How to guide" section to learn more about adding table summaries to tables
Adding Buttons and Links
Just like images, links should always have a title if it is to be used as a placeholder or anchor tag. that is it has no content within the <a></a>
tag.
Tip for buttons
: When using <div>...</div>, <span>...</span>, or <a>...</a>
as buttons always add a role="button"
attribute to the html tag. The button role should be used for clickable elements that trigger a response when activated by the user. Adding role="button"
will make an element appear as a button control to a screen reader. This role can be used in combination with the aria-pressed
attribute to create toggle buttons.
The above example creates a simple button which is first in the focus order.
Audios & Videos
Youtube videos:
HTML videos:
Other video types:
This guide is Drupal specific. This will help content editors using Drupal to add content to the website. It will also help with troubleshooting issues that may arise.
Adding images/svgs
SVGs - please remove all "id" attribute in the svg. It is always the same and creates a BIG error when the browser sees the same id for so many images/svgs
Images: Always add a title or alt tag to an image. But, make it meaningful. See example below.
Editing/Adding Tables
Adding Tables: Always make sure you add a table title and/or summary and/or caption
Adding nofollow and/or hiding pages
Production: https://access.boston.gov
Adding iFrames
Production: https://access.boston.gov
Content Editor Guide
The links with the same name should have the same href values when on the same page
Using classes on html elements you want to hide from screen but allow screen readers to access:
Iterators is a Certified Trusted Tester by the Department of Homeland Security and provides a code inspection-based test approach for determining software and web conformance to Section 508 standards.
Visit them at: https://iteratorstesting.com/services/accessibility-testing
Trusted Tester Tests: The Section 508 Trusted Tester program groups the WCAG requirements into related groupings that can be tested (and developed) at the same time. With the help of Iterators the VPAT documentation for boston.gov was created. You can read the documentation here.
Test #4) Keyboard and Focus
Purpose:
Many different types of users decide to use a keyboard to navigate a web page. Some
examples are screen reader users that will tab through an interface. Other users have
motor impairments and must control a computer through a switch (such as puffing into a
straw, etc).
People that use a mouse can quickly navigate a website. Additional design features are
needed to allow the same level of access to people that use a keyboard to navigate a user
interface.
Requirements:
1) Users should be able to access all functionality by using only the keyboard.
a. First, use a mouse to identify all functionality (buttons, links, etc)
b. Second, try to utilize all of the same functions using the keyboard, mainly using the tab and enter keys.
c. This also applies if popup features are implemented, such as an informational dialog, etc.
2) Tabbing through a user interface should occur in a logical order that matches the visual pattern on the screen, such as left to right, top to bottom.
3) Tabbing through a user interface should cycle completely through the interface and not be “trapped” in a cycle.
4) Focus is visible when using a keyboard
a. Sometimes a blue border is used to show the currently active element when using a keyboard. This should be easily visible with all elements.
b. Sometimes using a mouse will also highlight an element or reveal some information. These two methods should be compatible with each other.
c. The focus should always be visible and there should not be any invisible elements when using a keyboard.
Test #9) Repetitive Content
Purpose:
It is easy to skip over content using a mouse. However, keyboard navigation users must traverse many repetitive elements such as menus.
Requirements:
1) Identify all areas of a page with repetitive content.
a. A typical example is the navigation menu at the top of web page.
b. Some web pages have multiple sections of different content, such as “news”, “events”, etc. If there are many sections, then a user might like to skip the “news” section and jump to the next section without traverse all of the elements in that section.
2) Provide a “Skip” link, such as “Skip to Main Content” for each of these repetitive areas. This skip link is typically only visible when a user is using a keyboard to navigate through a web page.
Test #6) Links & Buttons
Purpose:
Keyboard users should be able to determine the context for any link or button. Often
users determine the context by visually examining nearby text or graphics.
Additionally, some links and buttons cause a change in content on a website which is
visually observable and also needs to be accessible to keyboard users.
Requirements:
The major requirement is that accessible and unique descriptions are available for each
link and button. For example, a set of links to news events might be labeled as “Read
More…”. However, the user may not be able to determine which news event is
associated with each link. The link may still be labelled as “Read More…” as long as
there is also accessible text that provides more description, such as “Read More about the
City of Boston”.
Any new content that becomes visible with a link or button should be identified with
accessible text before the user clicks on the link or button. An example of this is a
“Learn More…” button that causes a new modal dialog to be shown. Also, the keyboard
navigation should move to the new content.
Environments
Production: https://boston.gov
Articles, links, tools, and other programs to help us understand accessibility.