Public GIS applications give residents direct access to property records, assessment information, zoning data, public services, and other location-based resources. As local governments prepare for new federal accessibility requirements, these applications need to work for people who navigate websites using keyboards, screen readers, voice commands, magnification tools, and other assistive technologies.
The U.S. Department of Justice requires state and local government web content and mobile applications to conform to Web Content Accessibility Guidelines Version 2.1, Level AA, commonly called WCAG 2.1 AA. Following a 2026 deadline extension, public entities serving 50,000 or more people must comply by April 26, 2027. Smaller public entities and special district governments have until April 26, 2028. (ADA.gov)
For GIS departments, assessors, IT teams, and local government administrators, the practical question is clear: Can every resident access the information and services available through your public GIS?
Public GIS Applications Are Within Scope
The accessibility rule generally applies to web content and mobile applications that a public entity provides or makes available. This can include:
- Public property and parcel viewers
- Land records search applications
- Tax and assessment information
- Zoning and planning maps
- Election and voting maps
- Parks and recreation maps
- Emergency information applications
- Permit and inspection systems
- Online forms and search tools
- PDFs, tax maps, plats, and downloadable reports
- Mobile applications used to access public services
Using a third-party vendor does not automatically remove the government’s responsibility. The Department of Justice states that content provided through contractual, licensing, or similar arrangements is generally covered. It specifically identifies third-party maps and other technology tools posted by a government as content that usually needs to comply. (ADA.gov)
This makes public GIS accessibility a shared responsibility. GIS, IT, communications, accessibility staff, procurement teams, application developers, and technology vendors all have a role.
What WCAG 2.1 Level AA Means for GIS
WCAG 2.1 AA establishes testable requirements for making digital content perceivable, operable, understandable, and robust.
For a GIS application, compliance involves more than changing website colours or adding alternative text to a map image. The entire user journey needs to be evaluated, including how someone:
- Finds the application
- Searches for an address or parcel
- Moves between controls
- Selects a property
- Reads the resulting information
- Changes visible layers
- Accesses documents
- Completes forms
- Exports or prints information
- Obtains the same information without relying exclusively on a visual map
Interactive maps are complex because they communicate information through location, colour, shape, symbols, labels, movement, and spatial relationships. Each of those elements needs to be considered during an accessibility review.
10 Public GIS Accessibility Checks
1. Can the application be operated with a keyboard?
A resident should be able to access essential functions without using a mouse or touchscreen.
Test whether users can:
- Reach interactive controls using the Tab key
- Move backward using Shift and Tab
- Activate buttons and links using Enter or the space bar
- Navigate search results
- Open and close panels
- dismiss pop-ups and dialog boxes
- See which element currently has keyboard focus
- Complete a task without becoming trapped in a widget
A visible focus indicator is essential. Users need to know where they are as they move through the interface.
2. Does the keyboard order follow the visual layout?
Keyboard focus should move through the application in a logical sequence. A user should not jump unpredictably from the search bar to the footer, back to the map, and then into a hidden panel.
ArcGIS Experience Builder includes accessibility settings that can help establish a logical tab order. However, layout changes, overlapping widgets, custom components, and older configurations can still create problems. Esri recommends using its accessibility controls and testing the completed application rather than assuming the default configuration is sufficient. (Documentation)
3. Can a screen reader understand the application?
Buttons, inputs, search fields, map controls, and status messages need meaningful programmatic names.
A screen reader should identify a control as “Search by parcel number,” for example, rather than announcing “button” or an internal widget name. Form fields should have labels, headings should follow a logical structure, and dynamic changes should be announced when necessary.
Testing should include common combinations such as:
- NVDA with Chrome or Firefox on Windows
- VoiceOver with Safari or Chrome on macOS
- VoiceOver on an iPhone or iPad
Experience Builder supports screen readers, although Esri notes that behaviour can vary between browser and screen-reader combinations. Some map-related interactions may also have accessibility limitations, especially when drawing tools or custom widgets are involved. (Documentation)
4. Does every meaningful visual have an appropriate text alternative?
Logos, icons, charts, screenshots, map legends, and instructional graphics need text alternatives when they communicate information.
A short alternative may be sufficient for a simple icon. A complex map may require:
- A concise map description
- A written summary of its purpose
- An accessible data table
- A searchable list of results
- A longer explanation of important geographic patterns
W3C recommends providing complete text equivalents for complex images when a short description cannot communicate the same information. (W3C)
5. Is colour contrast sufficient?
Text generally needs a contrast ratio of at least 4.5:1 against its background. Large text may use a minimum ratio of 3:1. User-interface components and meaningful graphical objects also generally require a contrast ratio of at least 3:1.
GIS teams should test:
- Text and labels
- Search fields
- Buttons
- Selected and unselected controls
- Focus indicators
- Parcel outlines
- Map symbols
- Charts and legends
- Error and confirmation messages
Default Experience Builder themes are designed with contrast considerations, but custom colours still need to be checked. (WAI)
6. Does the map communicate information without relying on colour alone?
A map that uses only red and green to distinguish categories may be difficult or impossible for some users to interpret.
Combine colour with other visual cues such as:
- Different line styles
- Patterns or textures
- Distinct symbols
- Clear labels
- Text descriptions
- Data tables
- Filtered lists
Legends should clearly explain the visual system, and important findings should also be stated in text.
7. Are property searches and forms properly labelled?
Parcel viewers often rely on search fields for owner names, addresses, parcel numbers, subdivisions, and other records. Each field needs a clear, persistent label.
Placeholder text alone is not a sufficient label because it disappears when the user begins typing. Error messages should explain what went wrong and how to correct it. Required fields should be identified programmatically rather than by colour alone.
Search results should also be accessible without requiring users to select a feature visually on the map.
8. Is there another way to access the map’s information?
Some spatial relationships are difficult to reproduce through text alone. That does not mean the information should become unavailable to people who cannot see or manipulate the map.
Depending on the application’s purpose, provide options such as:
- An accessible property search
- A structured list of results
- A properly marked-up data table
- A downloadable accessible dataset
- Written directions or location descriptions
- A telephone or email support channel
- Accessible property reports
- A narrative summary of the map’s main findings
The alternative should provide meaningful access to the same service or information. A generic statement telling users to call the office may be inadequate if other residents can complete the task independently online.
9. Are downloadable documents accessible?
Public GIS applications frequently link to tax maps, property cards, sketches, reports, deeds, plats, notices, and other electronic documents.
Review documents for:
- Searchable text
- Correct heading structure
- Logical reading order
- Document titles and language settings
- Alternative text
- Tagged tables
- Descriptive links
- Sufficient contrast
- Accessible form fields
- Instructions that do not depend only on colour or position
The rule contains limited exceptions for certain archived and pre-existing documents. Those exceptions are fact-specific, and existing ADA obligations related to effective communication still apply. Current documents and documents that are updated after the compliance date may need to meet the technical standard. (ADA.gov)
10. Has the application been tested by people?
Automated testing tools can identify missing labels, contrast failures, structural errors, and some keyboard problems. They cannot determine whether a resident can successfully complete a real task.
Manual testing should include scenarios such as:
- Search for a property using an address.
- Review the property details.
- Identify the applicable zoning designation.
- Open a linked property document.
- Find the department’s contact information.
- Complete the same process using only a keyboard.
- Repeat the process with a screen reader.
- Test the application at 200 percent zoom.
- Test it on a mobile device.
- Confirm that error messages and status updates are understandable.
Testing should continue after launch and after significant application, data, or content updates.
A Practical Public GIS Accessibility Audit
Local governments can begin with five steps.
Step 1: Build an inventory
Document every public-facing GIS application, map, dashboard, mobile app, form, report, PDF, custom widget, and embedded map. Record the platform, owner, vendor, audience, usage level, and business purpose.
Step 2: Prioritize critical services
Start with frequently used applications and services that affect taxation, property research, permitting, voting, public safety, transportation, and other essential activities.
Step 3: Test complete user journeys
Review what residents are trying to accomplish. Test the full process rather than checking individual pages or controls in isolation.
Step 4: Create a remediation plan
Separate problems into categories such as:
- Content and labels
- Colour and visual design
- Keyboard navigation
- Screen-reader compatibility
- Documents
- Data alternatives
- Platform configuration
- Custom development
- Vendor-dependent changes
Assign an owner and target date to every issue.
Step 5: Establish ongoing governance
Public GIS accessibility needs to become part of procurement, application design, publishing, quality assurance, training, and maintenance. Include accessibility requirements in contracts and require vendors to explain how their products support WCAG 2.1 AA.
How Sidwell Can Help
Sidwell helps local governments assess, modernize, and maintain public-facing GIS environments.
Our team can support organizations with:
- Public GIS application inventories
- Workflow and accessibility assessments
- ArcGIS Experience Builder implementation and configuration
- Public property and land-records applications
- Portico implementation
- ArcGIS Online and ArcGIS Enterprise services
- GIS strategic planning
- Application modernization
- Staff training and ongoing support
Portico provides a centralized application for searching, retrieving, and displaying GIS, tax, and CAMA information. Sidwell can also help local governments evaluate how public information is presented across Portico, Experience Builder, and other web GIS applications.
The compliance extension provides additional planning time. It should be used to inventory applications, identify barriers, establish ownership, and begin remediation before accessibility becomes a deadline-driven emergency.
Contact Sidwell to discuss a public GIS accessibility assessment, consultation, or application modernization plan.
This article provides general information and does not constitute legal advice. Public entities should consult qualified legal and accessibility professionals regarding their specific obligations.
Do public GIS maps have to comply with the ADA?
Public-facing GIS maps provided or made available by state and local governments are generally within the scope of the Title II web and mobile application accessibility rule. Whether an exception applies depends on the specific content and circumstances.
What accessibility standard applies to local government websites?
The Department of Justice rule uses WCAG 2.1 Level AA as the technical standard for state and local government web content and mobile applications.
When do local governments have to comply?
Public entities with populations of 50,000 or more generally have until April 26, 2027. Smaller public entities and special district governments generally have until April 26, 2028.
Is ArcGIS Experience Builder accessible?
Experience Builder includes support for keyboard navigation, screen readers, alternative text, headings, focus indicators, and colour contrast. Accessibility still depends on the selected widgets, configuration, content, customizations, and completed application.
How can a map be made accessible to a screen-reader user?
Provide meaningful labels, a clear map description, accessible search functions, structured results, keyboard-operable controls, and another way to access important map information, such as an accessible table, list, report, or narrative explanation.