This is the English version of an article for the Team-Usability project about the accessibility of the FlixBus booking process.
Hier gehts zur deutschen Version…
Especially for people who cannot or are not allowed to drive their own vehicle due to their impairment, public transport is usually an indispensable part of their everyday life. In addition to local public transport, long-distance trains and buses play a particularly important role.
FlixBus is Germany’s largest long-distance bus provider. Behind this is the FlixMobility GmbH, a young mobility provider based in Munich. Since 2013 – under the brand name FlixBus – a steadily growing long-distance bus fleet has been operating on a route network throughout Europe. Since 2018, the company has also been offering its first railway services under the FlixTrain brand.
The basis of their success – according to the long-distance bus provider on its website – is the digitalization of the booking and ticketing system. But how well can their digital services be used by people with disabilities?
Patrick Dembinski, future IT salesman and blind since birth, has taken a closer look at the website flixbus.com. With his screen reader JAWS, he has gone through an exemplary booking process and documented what works well and what doesn’t work well. This should provide guidance to improve the accessibility of the mobility provider’s digital services.
Dembinski’s project fits well into our “Team Usability” project, since we can use his practical test procedure to clarify questions that are important for method development, such as
- Which specifications are useful for a practical test?
- What are suitable formats for documenting test procedures and results?
- Which working methods are suitable for team testing?
- How valid or meaningful are the test results – compared to an expert test – and how can validity be improved?
Dembinski’s research results were therefore analyzed and quality assured by his sighted colleague Simone Lerche. In addition, she added individual accessibility aspects for sighted users, such as contrast ratios and keyboard operability. The analysis of the test procedure and the cooperation in the team are summarized in an article (only in German): Der FlixBus-Test – Ein Test-Szenario, viele Erkenntnisse.
Search and book a FlixBus connection as a blind user
Test environment: PC, screen reader: JAWS 2019/ occasionally NVDA 2019.2, browser: Mozilla Firefox Quantum 69.0.1 (general note: users’ test results may vary based on screen reader and browser combination or individual usage patterns).
If you visit the FlixBus website, you can search for a connection directly on the homepage. But only visual users recognize this. As a screen reader user, I all of a sudden stumble upon the connection search element without warning by reaching the “Berlin text field” according to JAWS and figuring what this could be. It would be helpful here to label the search mask and the individual form fields in a meaningful way. Placeholder text, on the other hand, should not be used as a label.
Selection of start and destination points
Values are already predefined in the first two fields for the start and destination points (from: Berlin and to: Munich). However, the predefined location for the start point has nothing to do with your current location. Regardless of accessibility issues, it would be convenient to preset the current location. As a user, I have to enter the start point in the already mentioned “Berlin text field”: After manually entering a location, in my case Hamburg, I assume that I have provided the “input” as requested, so I tab onwards to the next field. But as I move on, my input is been reset to the default value “Berlin”. However, I am not aware of this at first, because the drop-down list that appears when entering a location is not announced. Only because I go back again to check if my start point has been stored correctly, I notice that it didn’t work out and that I have to go through an additional step.
Since I can’t cycle through the choices that appear below the text field in a list of suggestions (Hamburg, Hamburg Airport) with the arrow keys as usual, I reach the choices marked as buttons only after I leave the form mode. Now I can use the arrow keys (up and down) or the shortcuts f and b to jump from button to button and make my choice. Tabbing is not possible; otherwise one would land directly in the next field.
Date selection
The current date is predefined as the trip date. Nothing can be entered manually because it is a read-only field (confusingly, the screenreader says and displays: “write something…, read only”). I don’t immediately see how I can move on now. With the arrow keys I navigate through the surrounding elements and reach an unlabeled button. Just out of curiosity, I press the Enter key: It reveals a Date Picker, which I only reach after a few unsuccessful attempts. A table appears for each month, which rows represent the weeks and which columns represent the weekdays. The months are separated by headings. Since JAWS only reads the number to me, but not the day of the week, I can only tell from the column number (1 to 7) which day of the week it might be. Some days can be activated with Enter; some days cannot be selected at all. I eventually manage to select a working weekday, but I don’t get that announced either.
Enter the number of travelers
The next form field defines how many people travel with you (default: 1 adult). When the read-only field is focused, a window is displayed for visual users, through which a number for adults, children and bicycles can be stored. The values in the displayed window can then be adjusted either by manual input in the text fields or via the unlabeled buttons (minus/plus). But even this functionality is difficult to use with the keyboard and for me as a screenreader user it can only be used with trial-and-error and a lot of patience. Finally, I can complete my connection search by clicking on the “Search” button below.
In the Flixbus Shop
After the connection search you reach the FlixBus shop and a list of available connections, their details and a button to reserve seats will appear according to the specified parameters. Since this list is not shown correctly as a table, as a screen reader user I cannot navigate comfortably in it, but have to go through all elements one by one – a tedious thing. I reach the filters that are supposed to simplify the search, but I cannot access all of them with my screen reader.
When I select a connection using the “Reserve 1 seat” button, the button labels change to “Remove 1 seat” (for the selected connection) or “Replace 1 seat” (for the not-selected connections). Although I have selected a connection that I would like to book, I have to wander through the entire list until the shopping cart appears at the very end. In addition, a timer shows how long the seats are reserved for (starts at 30 minutes). With the button “Book” I reach the next page.
On the following page, some personal data will be requested from each fellow traveler. You also have the option of booking an insurance for the booked trip, reserving seats or booking additional luggage.
- Book an insurance policy: For test purposes I test the booking of an insurance policy. By clicking on the “Add” button, I am offered a selection of insurance policies that I can browse with the arrow key (but not with the tab key). When I select one of the insurances, a luggage insurance, additional information about the insurance conditions and a check box for each traveler appear. After I have answered all the questions, I can click on “Confirm” to add the insurance. Works fine so far.
- Reserve seats: In the next element I should be able to reserve seats. Clicking on “Reserve” opens the seat selection, but it is not accessible with my screen reader at all: I cannot select or reserve a seat. Thank God FlixBus connections can’t be overbooked, but the question still arises as to which seat you eventually get.
- Book additional baggage: The registration of additional luggage, on the other hand, works well again.
After activating a last checkbox to contribute a climate contribution, I reach the “Proceed to payment” button.
Payment process and booking completion
On the next page, you should select the payment method. However, this is a little tricky, because the radio-buttons you have to activate to pay via PayPal or Visa, for example, are not labeled and therefore unrecognizable to me. I puzzle my way through the missing information by searching through the different content depending on the chosen payment method appearing below. I decide in favor of PayPal and in the next step I am directed to the PayPal website, where you complete the payment process and thus also the booking and are redirected back to the FlixBus website. Of course, I did not go through this process for the test. The ticket, however, could be reviewed and printed out later from the website and received via the e-mail address provided in the payment process.
Accessibility aspects for visual users
After Patrick Dembinski had tested how accessible the FlixBus search and booking is for him as a screen reader user, Simone Lerche traced his results from a “sighted” expert perspective and analyzed them for method development in the project. Individual results of the short test concerning accessibility aspects for sighted users were briefly summarized here:
Keyboard operability and keyboard focus
Although blind users also need keyboard usability, we have tested them again: What for? The results of keyboard usability for screen reader users may differ from those of a sighted keyboard user. This is because screen readers can partially compensate certain barriers. Nevertheless, keyboard usability must also work for people who work without a screen reader, such as users with physical disabilities.
The connection search on the FlixBus start page cannot be used with the keyboard: Although the form fields can be reached with the tab key, you cannot enter your start and destination points manually, nor can you reach the suggestions of the drop-down list via the keyboard. Also the date can neither be entered manually, nor selected via the keyboard inaccessible Date Picker. The input field for the number of passengers or bicycles is focusable, but also not keyboard-operable. In the FlixBus shop too, there are clear problems with the lack of keyboard operability: In particular, the dialog window that appears on the right-hand side for booking insurances, seats or additional luggage is only reached by using the keyboard after you have cycled through the original page. This could be done in a more logical order.
In addition, the highlighting of the keyboard focus is missing, i.e. as a sighted keyboard user I never know where I am on the website.
Colour contrasts
People with visual impairments who orient themselves visually need good contrasts, especially with control elements. Here too, the website of FlixBus should be optimized: The yellow “Find connection” button, for example, only displays a contrast ratio of 1.9:1 in the corresponding analysis program, the “Colour Contrast Analyzer”. The grey button for switching directions has a contrast ratio of 3.1:1. Both are not sufficient for people with visual impairments (and not particularly comfortable for people who surf mobile in glare): Standard conformity would be a contrast ratio of at least 4.5:1.
Since the design in the shop picks up the colours of the connection search, the above described shortcomings of the contrast ratios also apply here.
If time limits cannot be switched off or extended, users who need more time for input – such as people with cognitive impairments – are often unable to complete online transactions in time.
Bottom line
Even if as an experienced screen reader user you can go through the booking process with a lot of patience and some help, there are many barriers.
This test is not a verification of compliance with the web accessibility standard, the Web Content Accessibility Guidelines (WCAG), but an individual practical test result for the usability of the website with the screen reader JAWS, the browser used and a very personal way of navigating web offers. In the team, we have only selectively added a few hints on accessibility for people with visual or physical disabilities or with cognitive impairments.
Overall, it can be seen that the accessibility of the website is expandable. There’s still some work to be done, FlixBus! As a passionate traveler, a barrier-free FlixBus booking for Dembinski would be a real plus. Moreover, the Directive (EU) 2019/882 of the European Parliament and Council on the accessibility requirements for products and services (European Accessibility Act) passed a legal act that will in future also oblige economic players such as passenger transport services in bus transport to provide barrier-free websites. Even if this is not in force yet, providers should take this into account.
Notes on implementation
- Developing a Date Picker that takes accessibility requirements into account is not easy. An example can be found at W3C under Date Picker Dialog Example. Otherwise it would be convenient to allow the manual input of a date as an alternative to the date picker.
- The same applies to the question of how to make a combo box accessible: Actually, that’s what the WAI-ARIA Authoring Practices 1.1, §3 combo box define. Some prefer the combo box according to WAI-ARIA Authoring Practices 1.0, others do not recommend the pattern in first place, e.g. because in some browser/tool combinations it does not support navigation in both form mode and read mode. Therefore, it would be good in any case to also allow manual input.
- You can find further information on how to develop accessible components at accessuse.eu and at w3.org/WAI/tutorials.
The way to my personal independence 