Screenshot of the Community Assets Map for the City of Riverview displayed on a desktop, tablet, and smartphone, featuring layers like community centers, libraries, parks, and public schools, with accessibility features highlighted. — Accessibility-first ArcGIS applications improve usability, compliance, and public access to geospatial information.

Introduction

Public agencies are increasingly expected to provide digital services that are accessible to all users, including individuals who rely on assistive technologies such as screen readers, keyboard navigation, voice input systems, or magnification tools. As accessibility standards continue to evolve, WCAG 2.2 Level A and AA compliance has become a major consideration for organizations deploying public-facing web applications.

Organizations implementing applications with Esri ArcGIS technologies should treat accessibility as a core UX, design, and engineering requirement from the beginning of a project rather than as a post-deployment consideration. Accessibility-by-design approaches not only improve compliance outcomes but also create cleaner user experiences, simpler workflows, and more usable applications for all users.

This article explores practical accessibility considerations for ArcGIS web applications, including implementation strategies for ArcGIS Experience Builder, ArcGIS Maps SDK for JavaScript, and ArcGIS Instant Apps. It also examines how UX design tools such as Figma can support accessibility-first planning and prototyping, along with testing recommendations and best practices that can help public agencies move toward WCAG 2.2 AA compliance.

Why Accessibility Is Challenging for GIS Applications

GIS applications present unique accessibility challenges because much of the user experience is centered around interactive, visual, and data-rich content. Unlike traditional websites or business applications, mapping applications often rely on dynamic maps, dashboards, popups, layers, and spatial workflows that can create barriers if accessibility is not intentionally incorporated into the design.

Many GIS workflows depend on interactions such as selecting map features, interpreting symbology, navigating layer controls, or analyzing geographic relationships visually. Traditional accessibility approaches designed for static content or forms-based websites often do not fully address the complexity of these map-centric experiences. As a result, GIS applications require specialized accessibility considerations to ensure users who depend on keyboards, screen readers, or other assistive technologies can effectively access information and complete tasks.

Common accessibility challenges in GIS applications include:

Interactive maps that require mouse-based navigation
Layer controls with limited keyboard accessibility
Color-dependent symbology without alternative indicators
Popups that do not properly manage keyboard focus
Dynamic content updates that are not announced to screen readers
Spatial workflows that lack accessible alternatives
Dashboards and data visualizations that are difficult to interpret using assistive technologies

By understanding these challenges early in the design and development process, organizations can build more inclusive GIS experiences while reducing the effort required to achieve accessibility compliance.

Understanding WCAG 2.2 AA Requirements for GIS Applications

WCAG 2.2 focuses on four principles:

Perceivable

Information must be presented in ways users can perceive.

Operable

All functionality must be usable through multiple input methods, including keyboards and assistive technologies.

Understandable

Interfaces and workflows should be predictable and easy to understand.

Robust

Applications must work reliably with assistive technologies such as screen readers.

GIS-Specific WCAG Considerations

Public-facing GIS applications commonly require additional attention around:

Keyboard navigation for map controls
Focus visibility and management
Accessible forms and filtering
Alternative workflows for spatial interactions
Color contrast in map symbology
Accessible legends and layer descriptions
Responsive design and zoom support
Screen-reader announcements for dynamic content

A graphic presenting the WCAG 2.2 Compliance Matrix for GIS applications, detailing accessibility principles, challenges, recommended mitigations, and examples.

Accessibility by Design for ArcGIS Applications

One of the most effective ways to improve accessibility outcomes in GIS projects is to incorporate accessibility considerations during UX planning and application design instead of treating accessibility as a remediation exercise later in the project.

Accessibility-by-design approaches generally produce better user experiences overall because they encourage teams to simplify workflows, reduce unnecessary complexity, and create more predictable interaction patterns.

This is also where UX design and prototyping tools such as Figma become extremely valuable during GIS application planning. Many accessibility issues can be identified long before development begins if teams incorporate accessibility reviews into the wireframing and prototyping process.

Figma allows UX designers, GIS analysts, developers, and stakeholders to collaborate around accessibility-first workflows before applications are configured in ArcGIS Experience Builder or custom-developed using ArcGIS Maps SDK for JavaScript. During design reviews, teams can evaluate:

navigation hierarchy
keyboard interaction patterns
responsive layouts
focus states
color contrast
modal behavior
workflow complexity
mobile usability

By validating accessibility considerations during the UX phase, organizations can reduce costly remediation efforts later in development.

Figma can also help establish reusable GIS design systems that standardize accessible components, spacing, typography, navigation patterns, and interaction behaviors across multiple ArcGIS applications. This becomes particularly valuable for public agencies managing multiple dashboards, web maps, and operational applications across departments.

In many cases, accessibility issues in GIS applications are not caused by ArcGIS technology limitations, but rather by workflow complexity and inconsistent interface design. Early-stage prototyping and UX collaboration can significantly improve accessibility outcomes before implementation begins.

For ArcGIS applications, accessibility planning should begin during discovery and wireframing. Teams should identify the primary user workflows, determine where accessibility barriers may exist, and evaluate whether alternative interaction methods are needed.

For example, if a workflow relies heavily on clicking map features, the application should likely include alternative list views, search-driven interactions, or accessible tabular interfaces that allow users to complete the same tasks without relying exclusively on map interaction.

A common accessibility issue in GIS applications is excessive interface complexity. Many applications attempt to expose every available GIS tool or layer directly within the interface. While technically powerful, these designs often become difficult to navigate and overwhelming for users.

Recommended UX strategies include:

Reducing widget overload
Prioritizing essential workflows
Using progressive disclosure techniques
Maintaining consistent navigation structures
Minimizing cognitive load
Avoiding unnecessary floating panels and modal interactions

Keyboard accessibility is another critical consideration. WCAG requires that all functionality be accessible without a mouse, which means GIS applications must support logical tab ordering, visible focus states, accessible dialogs, and keyboard-operable controls.

Applications with simpler interfaces and well-structured workflows are generally easier to navigate for all users, including those using assistive technologies.

An infographic titled 'Accessibility-First Design in Figma', outlining key considerations for planning accessible GIS experiences. It includes sections on keyboard navigation, color contrast, alternative text, information hierarchy, and responsive layouts. The central part displays a user interface design for a Public Works GIS application, showcasing layers, search functionality, and responsive layout previews for desktop, tablet, and mobile devices, emphasizing accessibility annotations and design handoff guidelines. — Accessibility planning in Figma can help identify UX and workflow issues before ArcGIS application development begins.

How Accessibility Is Implemented in ArcGIS Experience Builder

ArcGIS Experience Builder has become one of the most widely used platforms for developing modern ArcGIS web applications because it provides responsive layouts, configurable workflows, and a flexible low-code development framework. From an accessibility perspective, Experience Builder includes a number of built-in capabilities that can help organizations move toward WCAG 2.2 AA compliance.

Many of the standard Experience Builder widgets include built-in keyboard navigation support, responsive behavior, and improved focus management compared to older ArcGIS application frameworks. Theme-level controls also allow teams to configure typography, spacing, and color schemes that better support accessibility requirements.

However, accessibility compliance in Experience Builder still depends heavily on implementation decisions made during configuration and customization.

For example, accessibility issues commonly occur when organizations:

introduce overly complex layouts
use excessive floating panels or nested widgets
embed inaccessible third-party components
apply custom branding with poor color contrast
develop custom widgets without keyboard or screen-reader support

Custom Experience Builder widgets deserve particular attention. While the framework itself provides many accessibility improvements, custom React-based widgets can easily introduce WCAG compliance issues if they are not built using semantic HTML, proper ARIA labeling, and accessible interaction patterns.

In practice, some of the most effective accessibility strategies for Experience Builder applications are actually UX decisions rather than technical fixes. Keeping workflows simple, limiting unnecessary interactions, maintaining consistent navigation, and reducing interface clutter can significantly improve accessibility outcomes.

Organizations should also validate all Experience Builder applications through manual testing. Even when using standard Esri widgets, every configured workflow should be tested using keyboard-only navigation and screen readers to ensure the final user experience behaves as expected.

Screenshot of the ArcGIS Experience Builder interface showcasing features for building accessible and responsive layouts, including a widget library, design tools, and configuration options. — Standardized Experience Builder widgets can accelerate accessible application development when implemented correctly.

Implement Accessible Mapping Workflows

Not all users interact with maps visually.

Accessible GIS applications should provide alternative methods for accessing spatial information.

Recommended Alternatives

Search-first workflows
Accessible table and list views
Downloadable reports
Text summaries for spatial results
Accessible legends and layer descriptions
Non-map navigation options

For example:

A parcel viewer should allow users to search for parcels and review results in an accessible tabular format instead of relying exclusively on map interaction.

Synchronized map and accessible data table interface showcasing community infrastructure assets in Northview, including options to filter and find data, with features for improved accessibility and usability. — Accessible GIS applications should provide non-map alternatives for critical workflows and data exploration.

Accessibility Implementation in ArcGIS Maps SDK for JavaScript

ArcGIS Maps SDK for JavaScript provides significantly greater flexibility for building custom GIS applications, but it also introduces greater accessibility responsibility for development teams.

Unlike low-code platforms such as Experience Builder, custom JavaScript SDK applications require teams to directly implement and validate many accessibility behaviors themselves. While the SDK includes accessibility improvements such as keyboard navigation support, accessible zoom controls, reduced motion support, and enhancements for screen-reader compatibility, achieving WCAG 2.2 AA compliance still depends heavily on frontend engineering practices.

One of the most important considerations when building custom ArcGIS JavaScript applications is the use of semantic HTML structure. Custom interfaces should use proper headings, landmarks, buttons, labels, and navigation regions so assistive technologies can accurately interpret the application structure.

ARIA implementation is also commonly required for dynamic GIS workflows. Custom map widgets, expandable panels, dialogs, and data filtering interfaces often require additional ARIA attributes and live-region announcements so screen readers can communicate changes to users effectively.

Focus management is another critical area that is frequently overlooked in custom GIS applications. Applications should preserve logical focus flow, avoid keyboard traps, return focus appropriately after dialogs close, and ensure popups are keyboard accessible.

Map symbology and visualization design also play an important role in accessibility compliance. GIS applications should avoid relying exclusively on color differences or visual density to communicate information. Patterns, labels, icons, and textual descriptions should be incorporated whenever possible to provide alternative methods of interpretation.

Another important best practice is providing alternative workflows for map-based interactions. Critical business functions should never depend solely on clicking map features. Users should also be able to search, filter, browse, and review information through accessible forms, lists, and tabular interfaces.

Ultimately, accessible ArcGIS JavaScript applications require close collaboration between UX designers, frontend developers, GIS analysts, and QA teams. Accessibility cannot be isolated to a single implementation phase or technical role.

Diagram illustrating the Accessible ArcGIS JavaScript SDK Application Architecture, detailing layers such as UI Layer, Accessible Components, ArcGIS JS SDK Layer, Data Services Layer, and guidelines for accessibility features like Semantic HTML, ARIA, and Keyboard Navigation. — Accessibility in custom ArcGIS JavaScript SDK applications requires coordination across UX, frontend engineering, and GIS implementation.

Accessibility Considerations for ArcGIS Instant Apps

ArcGIS Instant Apps can provide a strong starting point for public-facing accessible applications because:

workflows are generally simpler
Esri maintains accessibility improvements centrally
templates often reduce custom-code risk

However, organizations should still:

test configured applications manually
validate branding and color choices
review keyboard workflows
ensure embedded content remains accessible

Screenshot of the Greenview County Parks Explorer web and mobile application, showcasing a map with parks, trails, and amenities. The design emphasizes accessibility features, responsive layout, and user-friendly navigation. — Simpler application architectures often improve accessibility outcomes and reduce implementation risk.

Accessibility Testing Recommendations

Accessibility validation should include both automated and manual testing to ensure compliance and usability. Automated tools such as axe DevTools, Lighthouse, and WAVE can efficiently identify common issues including color contrast deficiencies, missing labels, structural HTML problems, and ARIA implementation errors. However, automated testing alone is insufficient for validating complex GIS accessibility workflows and user interactions. Manual accessibility testing is essential and should include keyboard-only navigation, screen reader testing using tools such as NVDA, JAWS, and VoiceOver, zoom and magnification testing, mobile accessibility testing, and responsive layout validation. Testing should be performed against real-world user workflows and application functionality rather than relying solely on static page evaluations.

Infographic illustrating the GIS Accessibility QA Workflow, featuring five steps: Keyboard Testing, Screen Reader Validation, Mobile & Touch Testing, Automated Checks, and Real User Testing. Each section highlights tools, accessibility areas tested, and key devices for ensuring accessibility compliance. — GIS accessibility compliance requires both automated validation and hands-on workflow testing.

VPAT and Accessibility Documentation

Public agencies increasingly require accessibility documentation as part of software procurement, deployment, and compliance efforts. Typical deliverables include Voluntary Product Accessibility Templates (VPATs), Accessibility Conformance Reports (ACRs), accessibility statements, known issue documentation, and remediation plans. These documents provide transparency into an application’s accessibility posture, identify areas of noncompliance, and outline plans for addressing accessibility gaps. To remain accurate and useful, accessibility documentation should be maintained and updated throughout the application lifecycle as new features, enhancements, and accessibility improvements are implemented.

Infographic outlining the GIS Application Accessibility Compliance Documentation Checklist, detailing essential deliverables for accessibility due diligence and support compliance across five key areas: Plan, Build, Test, Document, and Deliver. Includes checklists and key contents for each area.

Common Accessibility Failures in ArcGIS Applications

Frequent issues include:

inaccessible custom React widgets
missing keyboard support
focus loss during map interactions
inaccessible popups and dialogs
color-dependent symbology
missing alternative workflows
inaccessible filtering interfaces
insufficient screen-reader support

Most accessibility failures occur in custom workflows rather than core Esri functionality.

Screenshot of an accessibility audit for a GIS web application by the City of Northview, highlighting common issues such as missing focus states, poor contrast, and non-accessible widgets. Includes a map, facility details list, and issue summary with critical, serious, moderate, and minor issues.

Recommended Accessibility Workflow for GIS Projects

A successful accessibility strategy should include:

Discovery

Accessibility requirements gathering
Compliance targets
User needs analysis

UX Design

Accessibility-first wireframes
Keyboard interaction planning
Accessible workflow alternatives

Development

Semantic HTML
ARIA implementation
Accessible component standards
Responsive layouts

QA and Testing

Automated accessibility scans
Manual keyboard testing
Screen-reader validation
Accessibility remediation tracking

Delivery

VPAT documentation
Accessibility statements
Ongoing monitoring and maintenance planning

Infographic outlining the GIS Accessibility Lifecycle, including stages: Accessibility Planning, UX Design, Development, Testing, Deployment, and Continuous Improvement, emphasizing the importance of accessibility for all users.

Conclusion

Accessibility compliance for GIS applications should not be treated as a final checklist item or post-deployment remediation effort.

Public agencies implementing ArcGIS applications should incorporate accessibility-by-design principles throughout UX planning, development, testing, and deployment.

Modern ArcGIS technologies such as ArcGIS Experience Builder and ArcGIS Maps SDK for JavaScript provide strong foundations for building accessible applications, but compliance ultimately depends on thoughtful UX decisions, accessible workflows, implementation quality, and comprehensive testing.

Accessible GIS applications improve usability for all users while helping agencies meet modern accessibility compliance expectations and deliver more inclusive public services.

GCS helps organizations design and implement accessible ArcGIS web applications aligned with WCAG 2.2 AA standards and modern UX best practices.

Need assistance evaluating or improving the accessibility of your ArcGIS web applications?

Contact GCS to discuss:

Accessibility assessments
UX/UI accessibility reviews
ArcGIS Experience Builder accessibility implementation
ArcGIS JavaScript SDK accessibility support
Accessibility remediation planning
VPAT and compliance documentation support

Contact GCS