WCAG 2.1 & Geospatial Information Science (GIS)/Maps

Key message

• Don't lock display orientation to either portrait or landscape. Some users will have devices with fixed orientation and others will change the orientation to improve visibility. Allow the user to choose. Do not force orientation unless it is essential.

How to implement

The CSS media feature can be used to obtain the orientation of the current view (based on height and width), allowing the page design to adjust accordingly. Additional options for detecting and responding to the orientation can be found in the Screen Orientation API.

ArcGIS Maps SDK for JavaScript MapView object has an orientation property that indicates the view's orientation. Preview your application in landscape and portrait mode to test compatibility. Most browser developer tools have options for simulating device orientation.

If needed, a control can be added to allow the user to choose the orientation.

Key messages

• Make it easier for the user to enter information by programmatically indicating the purpose of common inputs when technology allows for it. This facilitates autocomplete and helps assistive technology communicate the purpose of user input fields in alternative ways.
• This is typically achieved programmatically using HTML type and autocomplete attributes. There are a limited number of HTML type and autocomplete attribute options, and there will likely be user input fields in a web map application that do not have an appropriate type or autocomplete attribute value.
  • Keep in mind that the autocomplete attribute values apply to personal user information (such as their address, name, photo). They will not apply in a GIS situation when gathering information about other features.
    • For example, you would not use the "name" attribute for a field used to input the name of a place or the name of a photo. The "name" attribute would only apply to a field asking for the user's name.

How to implement

Use HTML type and autocomplete attributes to indicate input purpose when applicable.

Example of HTML code with input purpose for name, zip code and email:

Resources

• Input Purposes for User Interface Components
• H98: Using HTML 5.2 autocomplete attributes

Key messages

• Set size and position of the map element and UI components to maintain functionality at full zoom. Note: Mobile-friendly design helps meet this criterion.
• There is an exception for "parts of the content which require two-dimensional layout for usage or meaning." An example is maps.
  • Note: It is unclear whether this exemption applies to all map content a user can view through panning and zooming, which often cannot fit within a single view, or to the map element itself and its accompanying user interface components.
  • For this training, we assume the exemption applies to all map content the user could view. As a result, this training focuses on ensuring that maps and their accompanying UI components remain perceivable, operable, and understandable when users resize content through browser zoom. Designing with this expectation also helps make maps more mobile-friendly.
• The standard says functionality should be maintained at a zoom of 400% at 1280 horizontal and 400% at 1024 vertical. These dimensions will be referred to as "full zoom" throughout the training.

Maps

The map width should be dependent on the viewport width. The user should not have to scroll the page horizontally to see any part of the map element. Vertical scrolling is only appropriate if the map is part of vertically scrolling content. In this case, two-finger panning should be enabled. For full-page maps, the user should not have to scroll the page vertically to see any part of the map or access UI components. Containers of UI components and ancillary information may use vertical scrolling.

Buttons

If a map container is set to a percentage of the view height and/or width and widget buttons are stacked in a container along an edge, buttons may overlap at full zoom and become unusable.  

The application needs to be responsive to both the screen’s width and the browser’s zoom. When buttons begin to overlap, move all buttons to a single "tools" button that expands a pane of tools that scroll vertically and flow horizontally. When a tool is clicked on, hide the tool pane, then activate an event or open the next pane.

Pop-ups and panes

Set sizing for pop-ups and panes that do not require horizontal scrolling and do not overflow horizontally off the viewport at full zoom.

Legends

Many developers create and serve a static image for a legend. Avoid this and use images or SVGs for individual symbols on legend items and text for layer display names. ArcGIS Maps SDK for JS solutions include the Legend widget and the LayerList widget. If a static image for a legend must be used, ensure the image will fit the viewport width at full zoom (and make sure to use appropriate alt text).

Forms

Forms often collect inputs in maps, such as search terms. In desktop views, position labels inline with inputs. On mobile views, position labels above inputs.

Tables

Tables are exempt from limits on two-dimensional scrolling. Tables that support activities such as data comparison often require a wide layout, with records spanning a full row that may exceed even large desktop viewports. When possible, apply scrolling to the table container rather than the entire page. You may also consider whether the table content can be reorganized into one or two columns when viewed at full zoom.

How to implement

• Window: matchMedia() method
• Stack Overflow post on how to detect page zoom level in all modern browsers

Note: Many web resources support implementing responsive design, this list is not exhaustive.

How to test

• Any browser with developer tools that show or set screen dimensions.
• OS based commands for zooming content.

Resources

• ArcGIS Maps SDK for JS: Responsive apps using CSS

Key message

Ensure user interface elements (buttons, form inputs, etc.) and graphical elements (charts, graphs, etc.) have a 3:1 contrast ratio, where possible.

Examples

If the 3:1 contrast ratio is not met in the original design, use borders, spacing, or halos to separate the low contrasting colors. 

In color ramps, reduce the count of bins to allow for 3:1 contrast ratio between bin colors.

Testing tools

• WebAIM Contrast Checker or Colour Contrast Analyser
• Axe DevTools Browser Extension

Training

• W3C Schools: Understanding non-text contrast
• Office of Accessibility’s Word eLearning Module 3: Working with Colors
• Keep Minnesota Bright: Understanding WCAG 2.1, 1.4.11 Color contrast for non-text items
• How to Improve Non-text Contrast: Color Schemes and Interface Components (Understanding Success Criterion 1.4.11 Non-text Contrast)
• More Attractive, Engaging, Accessible: How To Use Color With Intention

References

• WebAIM Contrast and Color Accessibility: Understanding WCAG 2 Contrast and Color Requirements
• WCAG 2.1 & Content Authoring training page

Key message

• Ensure that content remains available, legible, and functional if users increase the text spacing of the web map application. The web application does not need to provide tools/options for users to increase the spacing. Users rely on their own tools and techniques. If content overflows a fixed-size container due to the spacing changes, it is acceptable to truncate with an ellipsis if the truncated text is still available (either on focus or as a linked page).
• The legend widget in ArcGIS Maps SDK for JS handles text spacing increases well, with wrapping text. Use brief layer names to reduce the amount of scrolling users need to view other legend items.
• Map pop-ups in the ArcGIS Maps SDK for JS resize dynamically when the text spacing changes, so there shouldn't be issues. If the pop-up has a lot of content, consider docking it.

How to test

To test an application for compliance, apply the following text spacing settings with a user-agent CSS file or a text spacing bookmarklet:

• Line height (line spacing) to at least 1.5 times the font size.
• Spacing following paragraphs to at least 2 times the font size. 
• Letter spacing (tracking) to at least 0.12 times the font size.
• Word spacing to at least 0.16 times the font size. 

Examples

Before text spacing is added:

After text spacing is added:

Testing tools

• Text Spacing bookmarklet

Key message

If a web application displays additional content when an element receives keyboard focus or mouse hover, ensure that these three criteria are met:

1. Content can be dismissed by pressing the Escape key.
2. Content is hoverable.
3. Content is visible until the user moves the hover, focuses on a different element, or dismisses the content.

This is particularly relevant for web maps that include vector data interactions or an identify tool. When users select features on a map: by clicking or hovering, ensure they can dismiss popups by pressing Escape or by selecting a different feature.

How to implement

• Technique SCR39: Make content on focus or hover hoverable, dismissible, and persistent

Key message

Character key shortcuts should only be active when the application has focus, be able to be remapped, or can be turned off.

Single-key shortcuts are an exception. While single-letter keys can be efficient controls for many keyboard users, they can create challenges for people who use speech input. When a single key trips a command, a spoken word can become a barrage of single-key commands if the cursor focus happens to be in the wrong place.

Key message

Multipoint gestures: such as pinch zoom that use more than one finger or pointer, must have single-point alternatives, such as zoom buttons or a double tap. Path-based gestures: such as freehand or streaming sketching, where the movement between the start and end points matters, must also have non-path-based alternatives, such as point-by-point sketching.

This requirement affects freehand drawing tools because they record movement. Editing points and vertices does not fall under this requirement because the intermediate positions are not recorded.

Key message

The objective is to prevent the user from taking unintended, irreversible action based only on a pointer-down event, such as a key press, mouse button press, or touching a control on a screen.

This can be accomplished in one of three ways:

1. The function only executes on the up-event (i.e., mouse button released, key press released, or touch removed).
2. The function executes on the up-event, and there is a way to cancel or undo the action.
3. The down-event results are reversible by the subsequent up-event.

Examples

1. The function only executes on the up-event: If a user clicks and holds down the button, and drags their mouse pointer around, nothing should happen until the user lets go of the mouse click.
2. If a user triggers a down event for a pointer, such as a key press or mouse press, the user should have a way to abort the action: If a user clicks and drags a dataset from a data catalog onto a map and has the data added to the display, the data should not be added to the map until the up-event occurs with the pointer over the map. If the user's up-event occurs elsewhere on the page, the "add data" action should cancel, and nothing should happen. It would also be acceptable if a confirmation dialog or undo option appeared after the data was added to the map to make the prior action reversible.
3. If there is a function tied to a down-event, the up-event should reverse it: If a down-event displays a pop-up dialog of attribute information for a feature, the up-event should make the same pop-up dialog disappear.

Key message

Ensure that controls, such as checkbox toggles for a table of contents (TOC) or legend/TOC, have labels that match or are contained within the text. For example, it would be confusing to have a programmatic/accessible label say "overlay1" when the text label says "watersheds."

• This guidance aligns with the "Forms and Labels" section of the State of Minnesota's Interactive Maps Guide. It's becoming more important because of speech-to-text input controls. For example, it's not accessible to have a group of checkboxes labeled with only "legend."

"Other text displayed on the screen that is correctly coded to meet 1.3.1 Info and Relationships is not normally factored into the calculation for the accessible name of a UI component without author intervention (via ARIA labeling techniques)." Also note that aria-label should be used with care: "Both aria-label and aria-labelled by take precedence in the name calculation, overriding the visible text as the accessible name even when the visible text label is programmatically associated with the control. For this reason, when a visible label already exists, aria-label should be avoided or used carefully, and aria-labelledby should be used as a supplement with care."

Example

Code Snippet with Label in Name:

How to implement

• Technique G208: Including the text of the visible label as part of the accessible name - Has examples of successful buttons & hyperlinks.
• Technique G211: Matching the accessible name to the visible label - Has examples of successful inputs like checkboxes.

How to test

Inspect the code when developing native HTML. If using frameworks that "automatically" create controls or ARIA labels, inspect the resulting HTML.

Key messages

The content of an application should not depend on device motion or user motion.

• This criterion applies to shaking or tilting a device or sensors that respond to the user's gestures.
• This criterion does not apply to the user moving through space and tracking location using geolocation sensors.

Examples

• Criterion applies: An augmented or virtual reality type of scenario where the user can explore a space based on the orientation of their device. The tilt or movement of the device would change the view of the scene. In this situation, the user should be able to achieve the same functionality using user interface components. The user should also be able to disable the motion control to prevent accidental use.
• Criterion does not apply: Mobile data collection apps that create a line or polygon feature based on the user's GPS track.

Key messages

Web mapping applications should use status messages to alert users when certain functions or tasks have finished running and to provide feedback during interactions. Below are several scenarios where status messages are essential:

1. Searching the map and returning results.
   • Indicate to the user that the search status is complete. The status message should include the number of results found (e.g., "Search returned 5 results").
2. Printing the map. Map applications often generate a PDF for download. Include a status message to notify the user when the PDF is ready to download.
3. User fills in a search form but the entry is not valid, or a required field is not filled in

Examples

Code Snippet of Status:

Code Snippet of Alert Message:

How to implement

Use role=status for elements, such as a count of search results, to let the user know that a search is complete (Technique ARIA 22).

Use role=alert in cases where required form fields are not completed or contain invalid values. Also use role=alert to provide suggestions for correction (Technique ARIA19).