Not everyone uses the web in the same way. Many people have disabilities that affect their ability to perceive or interact with content. Digital accessibility, at its heart, is about making sure the digital content we create (including web pages) are designed so that people with disabilities can access all the same content and perform all the same actions as people without disabilities.

It is essential that we create content with digital accessibility in mind. For those affected, the impacts are major - imagine being completely unable to access websites with important healthcare information, or even just not being able to order a pizza online. Further, the number of people impacted is probably considerably larger than you may realize:

  • People with permanent disabilities (visual, auditory, motor, cognitive, etc.)
  • People with temporary disabilities (in a loud environment, broken arm)
  • Older people (that will be you someday, if it isn't already)

Digital Accessibility Basics

There are many things to consider when creating accessible content. The goal of this theme/plugin is to make this a bit more manageable. While you still have to focus on general content accessibility, you at least should not have to worry if the provided color scheme, page structure, and other components of the website are accessible or not.

General content accessibility includes, but is not limited to:

  • Providing alternative text for images
  • Providing meaningful link text (not "here" or "read more")
  • Using the correct elements for different parts of your content (regular text vs. headings vs. lists, etc.)

For more information on general content accessibility, check out the following resources:

Continue reading for information on how the theme and plugin help create accessible websites, as well as specific things you need to be aware of to use them accessibly. And if you find anything in the theme or plugin that is inaccessible, please let me know!

Theme Accessibility

Using the Theme Accessibly

  • The styles as they are have been designed for accessibility. Be very careful in modifying these styles, whether the modifications are added within the content (e.g. via shortcodes) or as actual CSS (via the Custom CSS plugin).
  • If you upload a logo image, make sure to provide accurate alternative text in the provided configuration field. Remember that if you provide a URL for the logo to link to then the alt text should describe the destination of the link rather than the image itself.
  • If you turn off the automatically generated sitemap option, make sure you provide another method of navigating between pages beyond the main navigation menu. For example, you might include links to related pages on each page, or some "previous" and "next" links, depending on the kind of content you are creating.
  • Certain semantic HTML elements (<ins>, <del>, <s>, and <mark>) add hidden text before and after the element to inform screen reader users of the element. Therefore, make sure to only use these elements when they are semantically correct, or else visitors using assistive technology may be very confused!

There are lots of plugins that can be added to Grav sites, but make sure to test their accessibility carefully before doing so. Future goals for the theme include investigating particularly useful plugins and making sure the theme supports using them accessibly. Email me if you have a request regarding a specific plugin.

Theme Accessibility Features

A few accessibility features provided by the theme:

  • Semantic HTML used to designate the various regions on each page (header, nav, main, etc.)
  • Automatic sitemap generation (provides second way to navigate the site)
  • Color schemes tested for color contrast ratios (AA and/or AAA compliant)
  • Site includes option to have links default to opening in new tab - links that are modified by this option will announce this fact to screen reader users and will include an external link icon to let sighted users know what to expect
  • Certain semantic HTML elements (<ins>, <del>, <s>, and <mark>) add hidden text before and after the element to inform screen reader users of the element.

Plugin Accessibility

Using the Plugin Accessibly

  • Basemaps: If adding basemap images, make sure that the images do not include any meaningful content not presented elsewhere. At the moment, basemaps will be completely ignored by assistive technology, so screen reader users will not be able to get any information from any basemaps you use.
  • Basemaps in the Legend: If including basemap images in a tour's legend, consider providing some meaningful alternative text for the basemaps (alt text can be set for each basemap using the plugin config). While the images on the map itself will be ignored by assitive technology, this provides an opportunity for you to include some basic information. Remember that alt text should always be kept reasonably short.
  • Tile Servers: Like basemaps, tile servers are hidden from assistive technology. If your tile server includes any important information, make sure that information is provided somewhere else, too.
  • Feature color contrast: Make sure all features on the map/tile server have sufficient contrast such that they will show up clearly no matter what colors the map uses. Use two contrasting colors so that at least one of the colors will always show up well. Use a color contrast checker to verify that the colors you have selected meet requirements.
    • Make sure any images you upload for point feature icons have good contrasting colors.
    • Make sure lines and polygons have both stroke and border with good contrasting colors.
  • Feature icon alt: If the images or colors used to designate features on the map are meaningful beyond simply differentiating multiple datasets, make sure to provide alt text for them in the Legend Symbol Alt Text field (in the datasets or in the tour's dataset overrides).
  • Feature names: Give features meaningful names, as these names will be presented to both sighted users and screen reader users. However, keep the names relatively short. Long names risk being visually cut off due to the current tooltip styles (plugin will be updated as soon as this has been fixed).
  • Feature popup content: Consider adding popup content to features to describe any relevant geographic characteristics that might otherwise be noticeable by looking at the feature on the map (e.g. a long, branching river or a point located near a mountain). This will make sure that screen reader users can access this information, and it may help sighted users notice/reinforce it, too.
  • Feature order: Make sure features in a tour occur in a meaningful order. Anyone navigating the site via keyboard will experience the features in the order they were added to the map, so you want that order to make sense. By default this order is determined by the order of datasets in the tour and the order of features within those datasets, but you can override that by adding features to the tour's Features list.
  • Legend summary: Whether or not you are including a legend on your map, always use the Legend Summary field. This should be a short and sweet description of the dataset the features are from. For example, if you have a dataset of F5 tornadoes, you might provide a legend summary of "F5 tornado" or something similar. This would be very important if you also had, say, a dataset of F4 torandoes. If the F5 tornado dataset is the only dataset you are using, however, a legend summary may not be necessary (though it still might be helpful).
    • Keep in mind that this text will be added after the feature's name for each feature on the map (for screen reader users). Because it will be repeated often, even a full sentence might end up being a bit much. Use your best judgment in considering if the summary can be shortened without sacrificing important information.
    • The Legend Description will be used as a default if no summary is provided, but this should generally be avoided, particularly if you use markdown or HTML in the description. While the legend text will accept and display markdown and HTML content appropriately, which can be very convenient, the feature alt text cannot, and will instead have a bunch of special characters mucking up the readability of the text.
  • Headings: As with all content, make sure to use headings appropriately. Because tours have some additional built-in heading structure, it is important to mention this specifically. The tour title uses a heading level one (h1), so any headings in the tour's content should start at level two. Each view title uses a heading level two (h2), so any headings in view content should start at level three.

Plugin Accessibility Features

A few accessibility features from the plugin:

  • All features on the map are focusable, which means keyboard users can navigate to each feature and reveal its tooltip, even if the feature does not have popup content.
  • Feature tooltips are hoverable and dismissable. Hovering over the tooltip will keep the feature highlighted. Pressing Esc will close any visible tooltips (from hover or focus).
  • Each feature will present text to screen reader users including both its name and the legend description/summary provided for its dataset. Both of these values are customizable.
  • Shape features have an option to add a border so that you can have two different contrasting colors for a single feature.
  • Since showing the map and column side by side on small screens would make it hard to read either, at a certain screen size tours will shift into mobile view. In mobile view, users can switch between looking at just the content or just the map.
  • Modal dialogs are used for popup content and rely heavily on code provided from W3C to match the appropriate pattern for best accessibility.
  • If a tour has features with popup content, an additional page will be generated listing all popup content for features included in the tour. This provides another way of accessing this content besides clicking features on the map.