Accessibility is an integral part of HSL services, both in journey planning and physical access during travel. The registry also needs to comply with the accessibility WCAG 2.1 level AA requirements. The domain presents unique challenges for design, usability and accessibility: How to create an accessible, unified and easy-to-use user experience for complex and varied data sets? And accomplish this for different user roles and capabilities?
The registry is used by a group of public transportation planners, information planners, planning assistants and the maintainers of the physical infrastructure, such as stops and info spots. A smaller group of users means less diversity of users at any given point, but by no means less need for accessibility. Over its lifespan, HSL planners from diverse backgrounds will rely on the service. To put this into perspective, the existing registry has been in use since the 1990s already!
The JORE approach to accessibility has been pragmatic. All users benefit from great usability and clear navigation, keyboard shortcuts, descriptive labelling and logical service structure. The aim is to replace the existing system with a more transparent system that helps the user with e.g. previews and drafts before committing to updates.
An accessible registry benefits all users as well, including those facing temporary setbacks like fatigue or minor mobility impairments. It also ensures usability for long-term changes that come with aging.
Accessibility Design and the surprising benefits of loose visual branding
One of the requirements in accessibility design is empathy and the ability to assume the role of different users, with the aid of knowledge of the WCAG requirements. Once you’re working on the user experience, accessible design itself comes at little if no additional cost: Features such as contrast, target size, labelling, understandable hierarchy and descriptive headers are uncomplicated to design.
HSL has a comprehensive, branded component library that takes accessibility design into account. As JORE is an internal tool, it was deemed not to require branding as strict as the services that are on display to the public. In the JORE project, the components are used when they provide a clear-cut solution to a feature.
The semi-branded approach has the unexpected benefit of being able to use default browser components that require less visual tweaking or aria-labelling to be accessible. Making way for more default components could be considered also in more brand-oriented projects, to make the implementation of accessibility more straightforward.
Text and maps: Starting off with a conceptual division
Maps are a very visual tool with less strict hierarchies than, say, lists or tables. As such, maps present a unique challenge for accessibility. A public transportation system requires identifying changes in routes, or assessing the effects of a construction site to nearby stops. These are inherently visual tasks. Can we approach the issue differently, at least initially?
Early on in the project, we decided on a concept that separates work on a map and work that requires textual updates. It seems obvious that such a division exists, but there is some temptation to overlay forms or overly intricate features over the map if the user is already in map mode.
Text updates. Most of the work takes place in text form, without having to access the map. The emphasis on list views and text makes the management more accessible. The map is never just a background image for complicated updates that do not require a map.
Map mode. If an item needs to be viewed or edited on a map, such as a route, the map mode is easy to access. While in map mode, any selected route is also available as a list of stops next to the map, supporting keyboard use and even a screen reader. The concept was greenlit in early user testing.
Figure 1. An example of the list view and the map mode. The map mode is easily accessed when actual geographical context is needed, otherwise textual searches and updates provide a simpler layout for accessible use.
Moving forward with human-centred design
The agile project has covered three partially overlapping themes, each of them focusing on a crucial element of travel: Routes and lines, Timetables and Stops. In addition to constant smaller feedback, each theme has been evaluated three times in the design phase and once as a test version. The themes of each test has been as follows:
- Concept introduction with rough wireframes | Navigation, hierarchy and content
- Clickable Figma prototype | Usage paths, more detailed features
- Advanced Figma prototype | An updated version using user and developer feedback
- Documenting and prioritising features according to feedback
- Test version evaluation | Evaluating the implementation of the MVP
- Accessibility audit. The audit has been conducted for Routes and lines, the first module that was completed.
A number of evaluations of the complete set of modules are being planned.
Accessibility in focus: auditing the work done so far
While the user testing is helpful also for accessibility, a more targeted accessibility audit is needed to meet the specific requirements of WCAG. For this, an accessibility audit was conducted, using an accessibility expert outside the development team. The first audit for the project was done as the second phase of development was starting. At the time, the only finished module was Routes and Lines. The timetables module was under way.
The goals of the audit:
- Identify accessibility flaws in Routes and Lines
- Prioritise the findings and update the module
- Utilise the findings to update the best practices in order to avoid the most common errors thus far.
The findings were analysed and documented:
- Slide set with the finding and the corresponding WCAG requirement; severity of the observation and improvement proposal, often down to code-level suggestions
- Designs updated where necessary, to complement the fix proposal
- Project Wiki: Grouping of findings according to development themes and criticality
- Prioritised tickets in the project backlog.
After documenting, discussing and prioritising the findings of the audit, it was time to implement the suggested improvements.
Accessibility sprint: Addressing accessibility debt
Accessibility work is part of every-day development, but it was deemed useful to run a targeted accessibility sprint to reduce accessibility debt in the implementation. The heaviest priorities were given to the following features:
- Keyboard navigation
- Logical focus order
- Visibility of focus
- Proper labelling of visual items
- Semantic HTML
During the sprint, the prioritised issues were fixed. The most common issues and fixes were highlighted within the team to adjust working methods to reduce future faults. Issues that were not as critical for our particular group of users, such as detailed fixes to responsiveness and different devices were prioritised lower at this point.
Accessibility awareness for the stakeholders
Within the HSL team, accessibility awareness has been raised with sessions for the development team. Vincit also provides monetary incentive to experts who earn an accessibility certificate.
As a client, HSL takes the accessibility of its physical locations, journey planners and passenger information seriously. All HSL digital teams benefit from a dedicated channel to discuss accessibility issues and solutions. The project has also benefitted from a named accessibility supervisor and an HSL Accessibility Clinic, where the level of awareness and expertise for accessibility can be raised in each project team and issues discussed further.
Future evaluations and launch
As we approach the launch of the JORE Public Transportation registry, more user testing and an accessibility audit will take place. Continuous accessibility monitoring is also in the pipeline for automated tests.
In the same manner as each usability evaluation increases the usability of the service, each round of focused intention to accessibility will improve it. The intention is to increase the level of accessibility after each audit, through fixes and adoption of best practices in the development of future versions. By continuously learning from real-world use, we can ensure that JORE becomes an effective and accessible tool for years to come.
