Overview

This release focuses on WCAG 2.1 Level AA accessibility, building on a full accessibility audit of the Android app. It gives controls, icons, and list rows meaningful names for TalkBack, announces incoming dispatches, unit status changes, and offline state, improves readability at large font sizes and color contrast in light and dark themes, and adds keyboard navigation with visible focus plus a single-tap alternative to pinch-to-zoom on the map. It also restores full chat history, keeps users on the Hydrant Map after the phone sleeps, stops hydrant inspections from exiting after an image upload, and shows clearer login error messages.

New Features

• No new features are included in this release.

Feature Enhancements

Android Accessibility Improvements

• What - Completed a comprehensive WCAG 2.1 Level AA accessibility review of the Android mobile application and implemented accessibility improvements throughout the responder experience. The updates establish a stronger accessibility foundation for users who rely on screen readers, larger text, keyboard navigation, alternative input methods, and other accessibility features.
• Why - Responders use a wide variety of devices and accessibility tools in operational environments. Improving accessibility helps ensure important incident information, controls, navigation, and application feedback can be effectively accessed by a broader range of users.
• How
  • Accessibility improvements are automatically available after updating the Android application.
  • Continue using Android accessibility features such as TalkBack, increased font sizes, physical keyboards, or supported alternative input devices normally.
  • No additional First Due configuration is required.
• Use Case - A responder who relies on Android accessibility functionality can navigate the application and interact with operational information with improved labeling, announcements, readability, focus behavior, and interface structure.

Improved Screen Reader Labels and Control Names

• What - Improved screen reader support throughout the Android application by adding meaningful accessible names to previously unlabeled controls and removing decorative images from screen reader navigation. This reduces unnecessary announcements and makes interactive controls easier to identify using TalkBack and other accessibility tools.
• Why - Screen readers need to distinguish between meaningful controls and decorative interface elements. Proper labeling allows users to understand what an interface element does without relying on its visual appearance.
• How
  • Enable TalkBack or another supported Android screen reader.
  • Navigate through First Due using the standard accessibility gestures.
  • Interactive controls now provide meaningful names where applicable.
  • Decorative elements that do not provide useful information are skipped by the screen reader.
• Use Case - A TalkBack user navigating an operational screen hears the purpose of actionable controls instead of encountering unlabeled buttons or unnecessary descriptions of decorative images.

Accessible Status Indicator Announcements

• What - Improved accessibility for status indicators so supported icons announce their current state instead of providing a fixed or generic label.
• Why - A visual status indicator is only useful to a screen reader user when the current state is communicated along with the purpose of the control. Dynamic announcements provide the same changing status information that sighted users receive visually.
• How
  • Enable TalkBack.
  • Navigate to a supported status indicator.
  • TalkBack announces the indicator and its current state.
  • When applicable, updated states are reflected through the accessibility information presented by the application.
• Use Case - A responder using TalkBack can identify the current state of an operational status indicator without needing to visually interpret the icon.

Accessible Names Match Visible Controls

• What - Updated accessibility labels so supported controls use names that match their visible labels, including actions such as Login and Calculate Route.
• Why - Matching spoken and visible labels improves consistency for TalkBack users and helps users of voice-based accessibility tools accurately identify and activate controls.
• How
  • Use TalkBack, Voice Access, or another supported Android accessibility tool normally.
  • Supported controls now use accessibility names consistent with the text displayed on screen.
  • No additional configuration is required.
• Use Case - A user controlling the application through Voice Access can identify an action using the same wording displayed on the screen rather than encountering a different accessibility name.

Unique Accessibility Labels for Similar Controls

• What - Updated controls that previously shared the same accessibility label so each control can be individually identified by assistive technology. This includes controls with different purposes that were previously announced using identical names.
• Why - Duplicate accessibility labels make it difficult for users to determine which control they are selecting. Unique names provide the context necessary to choose the correct action.
• How
  • Enable TalkBack or another supported accessibility service.
  • Navigate between controls normally.
  • Controls with different functions now provide distinct accessibility names.
• Use Case - A TalkBack user can distinguish between controls such as Notifications and Always Play Sound rather than hearing the same description for both options.

Descriptive Incident and Unit Row Names

• What - Replaced generated accessibility names for supported incident and unit list rows with descriptive names based on the actual incident or unit information displayed in the row.
• Why - Technical labels do not provide meaningful operational context. Descriptive row names allow screen reader users to understand which incident or unit they are selecting.
• How
  • Enable TalkBack.
  • Navigate through supported Incident or Unit lists.
  • List rows are announced using available incident or unit information instead of generated row identifiers.
• Use Case - A responder using TalkBack can navigate an incident list and identify the actual incident represented by each row instead of hearing generic labels such as a numbered incident row.

Additional Screen Reader Control Labels

• What - Added accessible names to remaining identified unlabeled controls, including the Apply to All switch on the Alert Tone screen.
• Why - Every actionable control should provide enough information for assistive technology users to understand its purpose before interacting with it.
• How
  • Enable TalkBack or another supported screen reader.
  • Navigate to supported application controls.
  • Previously unlabeled controls now provide descriptive accessibility information.
• Use Case - A user configuring alert tones with TalkBack can identify the Apply to All switch and understand which control is being changed.

Dynamic Screen Reader Announcements

• What - Added improved accessibility handling for dynamic application changes so supported updates can be announced to screen readers as they occur without unnecessarily repeating the same announcement.
• Why - Important responder information can change without the user navigating to a different screen. Screen reader users need to be notified when meaningful changes occur rather than relying exclusively on visual indicators.
• How
  • Enable TalkBack.
  • Continue using the application normally.
  • Supported dynamic changes are announced automatically when they occur.
  • Repeated announcements of the same change are reduced.
• Use Case - A responder using TalkBack can receive spoken feedback when important information changes while remaining on the current application screen.

Operational TalkBack Announcements

• What - Expanded TalkBack announcements for important operational events, including incoming dispatches, unit status changes, online and offline state, location and GPS availability, and empty or error states within the Units, Incident, and Chat lists.
• Why - Operational changes communicated only through visual banners, icons, or messages can be missed by users relying on screen readers. Spoken announcements provide immediate awareness of these events.
• How
  • Enable TalkBack on the Android device.
  • Continue using First Due normally.
  • Supported dispatch, status, connectivity, GPS, and list-state changes are announced automatically as they occur.
• Use Case - A responder using TalkBack can hear that a new dispatch has arrived or that GPS availability has changed without needing to manually navigate through the interface to discover the update.

Text Scaling, Orientation, and Login Accessibility

• What - Improved accessibility by removing unnecessary screen orientation restrictions, correcting text that did not scale appropriately with device font settings, and adding autofill support to login screens.
• Why - Supporting device orientation, scalable text, and credential autofill makes the application easier to use for individuals who rely on larger text, specific device positioning, or Android accessibility and credential-management features.
• How
  • Adjust the Android device's font size using the normal device accessibility settings.
  • Rotate the device where supported by the applicable application screen.
  • Use supported Android autofill functionality on the Login screen.
  • No additional First Due configuration is required.
• Use Case - A responder using increased system font sizes can view supported application text at a more comfortable size while another user can use Android autofill to enter login information more efficiently.

Large Text and Color Contrast Improvements

• What - Improved the Incident Details and Incident List layouts at up to 200% font scaling and increased color contrast for supported interface elements, including the dispatch banner, brand colors, and disabled states across light and dark themes.
• Why - Larger text should remain readable without preventing users from accessing important controls or information. Improved contrast also helps users distinguish content and application states in varying lighting conditions and with different visual needs.
• How
  • Configure the desired font size through the Android device's accessibility settings.
  • Use First Due in the preferred supported light or dark appearance.
  • Updated layouts automatically accommodate larger text in the affected workflows.
  • Updated interface elements use the improved contrast automatically.
• Use Case - A responder using 200% font scaling can review the Incident List and Incident Details without important information becoming unusable, while improved contrast makes dispatch and status information easier to distinguish.

Keyboard Navigation and Focus Improvements

• What - Improved keyboard and alternative-input accessibility by removing identified focus traps in WebView content, correcting focus order, and adding a consistent visible focus indicator.
• Why - Users operating the application with a physical keyboard, switch device, or other alternative input method need to move predictably through controls and clearly identify which element currently has focus.
• How
  • Connect or enable a supported keyboard or alternative input device.
  • Navigate through application controls using the applicable input method.
  • Focus now moves through supported content in the corrected order.
  • The currently focused control displays a visible focus indicator.
• Use Case - A responder using a physical keyboard can navigate into and out of web-based content without becoming trapped and can visually identify which control will be activated.

Accessible Page Structure and Map Zoom Controls

• What - Improved application structure for assistive technologies by adding section headings, persistent form-field labels, content-language information, and consistent bottom-navigation naming. The map also now provides a single-tap zoom alternative for users who cannot perform a pinch-to-zoom gesture.
• Why - Clearly structured screens make complex application content easier to navigate with assistive technology, while alternative map controls ensure essential functionality does not depend exclusively on multi-touch gestures.
• How
  • Use TalkBack or another supported accessibility service to navigate available headings and labeled form fields.
  • Form fields such as those within Login, Chat, and Add Link retain identifiable labels.
  • Bottom-navigation options use consistent accessibility naming.
  • On the map, use the available single-tap zoom controls as an alternative to pinch-to-zoom.
• Use Case - A responder using a switch device can zoom the map without performing a two-finger gesture, while a TalkBack user can navigate through screen sections and identify form fields more efficiently.

Fixes

Full Chat History

• What - Fixed an issue where Chat could limit users to the 25 most recent messages. Older messages are now available so users can access the conversation's earlier history.
• Why - Operational conversations may contain important information beyond the most recent messages. Maintaining access to older chat history allows users to review previous communication when additional context is needed.
• How
  • Open Chat.
  • Select the applicable conversation.
  • Navigate through the conversation history to access older messages.
  • Chat history is no longer limited to only the 25 most recent messages by the identified issue.
• Use Case - A responder joining an ongoing operational conversation can review earlier messages to understand decisions and updates that occurred before the most recent portion of the chat.

Hydrant Map Resume Behavior

• What - Fixed an issue where the application could return users to the Responder Map instead of the Hydrant Map after the Android device went to sleep.
• Why - Users working with hydrant information should be able to resume the workflow where they left off rather than having to navigate back to the Hydrant Map after the device wakes.
• How
  • Open the Hydrant Map.
  • Allow the device to sleep or lock.
  • Wake and unlock the device.
  • The application now remains in the Hydrant Map workflow instead of incorrectly returning to the Responder Map.
• Use Case - A responder reviewing hydrants allows the device screen to turn off while traveling. When the device is reopened, the Hydrant Map remains available so the user can continue working without navigating back to it.

Hydrant Inspection Image Upload Workflow

• What - Fixed an issue where uploading an image during a hydrant service or inspection workflow could exit the active inspection and return the user to the Hydrants Map, potentially interrupting work in progress.
• Why - Images may be an important part of documenting hydrant condition and inspection activity. Uploading a photo should not interrupt the inspection or require users to re-enter the workflow.
• How
  • Open the applicable hydrant.
  • Begin the Service or Inspection workflow.
  • Add and upload the required image.
  • The active hydrant workflow now remains open after the upload so the inspection can continue.
• Use Case - During a hydrant inspection, a user photographs a maintenance concern and uploads the image. The inspection remains open, allowing the user to finish entering inspection information without losing their place.

Clearer Login and Authentication Errors

• What - Updated login and authentication error handling so the Android application displays more specific information returned by the authentication service instead of relying on a less descriptive general error message.
• Why - More specific error information helps users better understand why authentication was unsuccessful and determine the appropriate next step.
• How
  • Enter credentials on the Login screen.
  • If authentication is unsuccessful, review the error message displayed by the application.
  • The message now reflects the applicable reason provided by the authentication service when available.
• Use Case - When a user cannot sign in, the application provides more specific information about the authentication failure, helping the user understand the issue rather than receiving only a generic login error.