Accessibility: the case for better user experience (part 2)

A few days ago, we published the first part of our story about accessibility, and how we let our interface evolve to optimize user experience, whether one uses a screen reader, or needs increased contrasts to easily interact with our content.

Part 1 dealt with the definitions of accessibility and our work on color contrasts. Part 2 is now going to deal with screen reading and evolved interfaces, to allow for smoother decision-making in the business simulation, especially for non-sighted users.

Translating visual information for non-sighted users

The WCAG standard guidelines and principles also consider accessibility for non-sighted users. The implications of making our business simulation accessible to non-sighted users can be divided into two sub-projects.

The first sub-project was to make accessible to all users the information presented in the analytical section of the interface. In that section, results from teams are displayed across three pages: one is the dashboard, which compiles the core information based on which winners of the simulation are declared, the second compiles information related to finances and operations of the team – available to that team only -, and the last one compiles information from the markets and other teams, which enables participants to run competitive analyses.

The second sub-project was to rethink the way users with accessibility needs would go through the decision process after analyzing their team results, in the decision section.

For readers who are unfamiliar with accessibility matters, as we were until recently, non-sighted users can navigate web pages and documents using a screen reader. This tool is available free of charge and reads out loud the elements of the page, enabling non-sighted users to interact with that page without relying on visual information. This means that accessible pages and documents need to be able to convey the same information to non-sighted users as to sighted users, when being read by the screen reader.

If we focus on the first sub-project, which was making the non-decision parts (or analytical parts) of the interface screen reader friendly, three elements had to be taken into consideration:

(1) Ensuring that page navigation can be achieved smoothly by using just the tab and space keys, as these are the two main controls of the screen reader.

(2) Making sure that visual features of the page, such as the zoom button, the back-to-top button, icons are understood by the screen reader and convey the right information to the user.

(3) Letting the screen reader understand and read the information found in graphs in a way that is intelligible for non-sighted users and carries the same emphasis as for sighted users – i.e., no information distortion.

The first point is mainly related to the structure of a page: without getting into too much detail, a webpage is structured using title tags, giving information about the hierarchy of the page to the screen reader. This way, the tool knows that it should first read all the elements of the top menu, before reading the elements of the next level down.

In that example, the screen reader is expected to first read the menu elements at the top – dashboard, company, markets, etc. –, tell the user on which page we are now (dashboard) and then move on to reading the submenu elements – sales revenue, return on capital employed, etc.

The next point was about making sure that visual features are readable, and their use clear to the user.

If you take this visual from the financial section of the business simulation interface, there is a small magnifying glass in the upper right-hand corner. For sighted users, this icon sends a clear message that by clicking on this magnifying glass, more detail will be displayed to the user.

For the screen reader to interpret this icon properly and communicate the adequate message to non-sighted users, we relied on the ‘alt text’ technique. In the code of the interface itself, where the magnifying glass has been placed, we added a bit of text that will be read by the screen reader, so non-sighted users will hear something like “access information from more periods” or “button to access further details about that and that”.

The same principle was applied to the back-to-top button, which we find at the very bottom of the page, for example.

The last point to explore was to let the screen reader understand and communicate the information found in graphs across the whole interface, in such a way that users would understand as much – and the same information – as a sighted user.

All our graphs are visual representations of data in tables, but as we said earlier, visual representation has always been, in our opinion, a facilitator in helping business simulation participants understanding concepts we cover. This is especially true for participants with little to no prior knowledge of business concepts. This opinion, though, holds only for sighted users with a liking for visualization.

When using a screen reader, a graph gives little flexibility to browse through the information – that is why we decided to develop a second mode: one that converts all graphs into tables, thereby also impacting the section about decision-making, which we will cover later.

Placed right next to the ‘activate/deactivate high contrasts’ button, the ‘activate/deactivate screen reader mode’ allows students to adapt their own experience of the interface, be it to optimize the use of a screen reader, for non-sighted users, or because the participant prefers to visualize elements in a table format.

The benefit of a table format is that it allows us to influence the behavior of the screen reader, so it reads the data in such a way that conveys the same message as the visual representation.

Decision-making for non-sighted users

In the analytical section of the interface, users do not interact with the information, they just read it and analyze it – and in some cases, they select/deselect elements to isolate information.

The decision section in the original version of the game, though, is based on visualization of the value proposition for each business line, and on interacting with that visualization by moving sliders, typing in numbers, selecting, and deselecting toggle buttons, for example.

The decision section is organized by business line, each containing three subsections related to the value proposition, the value chain (or value architecture) and the budget (profit equation).

For all users, value proposition decisions are made against a set of marketing and engineering criteria. For sighted users, though, making a change in the value proposition section will have visual impacts, not only on the value proposition graph itself but also on the value chain section, where teams fine-tune their decision. Users then move to the budget page where current team results and decisions are consolidated, yielding a forecast of what they can wish to achieve during the next run. Finally, sighted participants navigate the corporate page, which consolidates all decisions and current results, yielding a forecast at the company level – which is also where some company-level decisions, such as HR & quality programs, are made.

But for a non-sighted user, the screen reader would have a hard time reading the change happening simultaneously on the value proposition page and on the value chain page, due to technological limitations.

Instead, we restructured the decision section with screen reader users in mind: the decision section was turned into a single page, divided into 5 subpages: one for each of the business lines, and one for the corporate decision, thereby allowing a smoother navigation across business lines.

Business lines decisions

Each of the business unit subpages includes all the information related to value proposition, value chain and budget, thereby circumventing the technological limitations of screen reading across pages.

First, users make their decisions against the same set of engineering criteria as in the regular interface, except that we integrated drop-down selectors instead of sliders. The value of the previous decision and of the market average are given in text format, and we added a column ‘evolution of engineering expense specific to dimension’ to translate the effect of the decision on the engineering expenses – the same information was communicated visually in the regular interface.

Every time that a user changes a value, the screen reader will read all the items that change on the page: for example, if I increase the consumption of the car in that business unit, the CO2 emissions will also rise, and the screen reader will let me know about it when I have updated the ‘consumption’ value.

The visual interface allows participants to keep a helicopter view of each business line, so they can see the concrete impacts of their decisions on their costs and their marketing/engineering appeal. For non-sighted users to benefit from the same approach, we created a new section that allows them to monitor the effects of their current decisions on fundamental metrics such as the engineering appeal or the capex per unit.

In our business simulation, it is also essential to keep an eye on trends and check one’s performance since the start of the game: this provides valuable insight into whether the team is making sound business decisions. For that purpose, we created an additional table gathering the data of the team in terms of engineering since the start of the period: if unit cost keeps going up, for example, it could be a sign that the team is not producing efficiently.

Further down on the same page, the participants of the game make their marketing decision, for which the structure is identical to the engineering decision: first they decide how marketing criteria will evolve, and how the team thinks their customer pool perceives the value proposition; then, they review the impacts of their decisions on marketing metrics; and finally, they monitor how metrics are trending since the start of the simulation and adjust based on potential identified issues.

The last section of the business line decision page is the budget decision: considering all decisions made further up on the page, the system will compute, given the team’s forecast, the unit cost for that business line and the available production capacity. Teams will choose their price and the quantities to produce accordingly, while making forecasts of how many items they expect to sell. Based on this, the system will generate a forecasted revenue, from which all expenses and costs will be deducted to yield a forecasted EBIT.

Corporate decisions

After the participants of the business game have made their decisions per line of business, they can select the corporate tab from the decision menu.

This page is divided into multiple sections that allow users to review their decisions for each product line and their consequences on the organization – for example, some business lines might have a negative cash flow while others have a positive cash flow, and this is fine, but if all lines have a negative cash flow, the team will want to assess whether this is a temporary situation or whether they can turn things around and whether they need a bank loan.

The first section is the sales report, which displays expected orders, sales, revenue, inventory, profit, etc. line by line and the evolution of those numbers since the last decision period.

The second section is the facility capacity report, where users can monitor all things capacity, capex and where they can make decisions related to facility investment – to grow their production line, for example. As with other decision pages in the screen reader friendly interface, making changes in facility investments will have impacts across the whole corporate page, which the tool will read out loud for users to be aware of.

The third section focuses on the cash impacts of the decisions, while the fourth section includes the remaining corporate decisions such as loans, loan repayments, HR expenses and dividends, for example. This is also where users will see how much cash at end they have, so they can readjust their decisions to get as close as possible to breakeven point – cash needs to be used!

Validate section

The last step to validate the team’s decision and save it into the system, is to navigate to the ‘validate’ page. This page is common to all interfaces and did not require any major change, as it is a table format: it consists of three sections, being the income statement, the cash flow statement, and the balance sheet of the team. Numbers displayed on that page are related to the current results, the forecasted results – based on the team’s own perception – and the difference between said forecast and the current period.

The game users are then invited to click (or select) the ‘send your decision’ button, which will double-check with the user, whether they have made decisions for all business lines. Et voilà!

What we learnt from this project

Looking back at this accessibility transition of our business simulations, it has been an exciting experience: it has been an opportunity for our team to gather, to think and debate, but most importantly to approach our own product in a new way. Our focus has been on content for a very long time, as we have been teaching business skills to employees and students for over 30 years, but since a few years, our understanding of user experience has expanded, and it has become a cornerstone of our new simulations. The exercise to make the game accessible was a milestone in this direction.

The exciting challenge about accessibility has been to understand user interaction with our interface in a completely new way, create enablers for this experience to be smooth and most importantly, for the user to take away the same learnings whether they have accessibility needs or not. Besides, this deep dive into user experience also helped us improve the interface for all users, by rephrasing some concepts that were ambiguous, clarifying some visuals that did not entirely convey the message we wanted to convey, and by providing more flexibility for all to play with the interface they are the most comfortable with: be it one relying on visuals, or on tables.

One advice we would like to give – and to keep in mind for our current and upcoming developments – is that transitioning to accessibility takes much more time and resources once the product has already been developed. User experience should be at the core of product development, as we like to teach our business game participants, and this includes users with accessibility needs. For example, our current development with the NYU Wagner School of Public Health has integrated user experience and accessibility from the start, and this has spared us time and money, which we can dedicate to other features of the new game.

There are users with accessibility needs everywhere. They might not be visible, but they are studying with us, working with us, and have the same right to enjoy the immersive experience our business simulations have to offer. We, as education providers, have a responsibility to make sure our content is accessible to all and that the user is at the heart of our developments, to help curb discrimination and give an equal chance to all students and employees to become talented business leaders, regardless of their needs.

If you would like to discover our new, accessible interface, get in touch now!

Demo Call

What if you saw our simulations for yourself? Let's jump into a short call and discuss your class or training needs, while exploring our interfaces and teaching material.

Pick a date and time