How to make Time Limits accessible

Timeouts are important in many security and data protection-related processes. They are intended to prevent other people from gaining access to sensitive data or processes. However, using them in an accessible manner is not trivial.

Common problems

The most common problems I have encountered in practice:

The timeout is not displayed at all. This is quite common. Think of the timeout in your banking app. You log in to the bank's website, a code is sent to your smartphone and if you do not confirm this code within a certain period of time, the process is aborted. But this is not displayed on the website or in the app. The same applies to the timeout in online banking itself. It is rarely displayed.
The time period is too short: you log in, get yourself a valerian tea, look out the window, and then you are thrown out and have to log in again. Three minutes is often common.
A process is aborted: you are completing a long form, you get a call in between and when you look at the screen again you are kicked out and have to start again.

The problem is that the time limits are designed for digital professionals. People who have little experience with the Internet or the specific application and need a little longer are not taken into account.

What the WCAG requires

At first let's take a look at the WCAG requirements specifically for this area.

SC 2.2.1 Timing adjustable

The decisive factor is SC 2.2.1: Timing Adjustable (Level A). The requirements from the understanding document:

For each time limit that is set by the content, at least one of the following is true: Turn off The user is allowed to turn off the time limit before encountering it; or Adjust The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or Extend The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar"), and the user is allowed to extend the time limit at least ten times; or Real-time Exception The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or Essential Exception The time limit is essential and extending it would invalidate the activity; or 20 Hour Exception The time limit is longer than 20 hours.Source

Switching off the time limit is probably not possible in most cases because it is necessary for security reasons. The 20-hour limit (how did they arrive at this number?) is also unlikely to work in most cases: The aim of time limits is to prevent unauthorized access to computers and most people do not sit 20 Hours in front of their computers. With a smartphone, you are usually logged out of the session if you turn off the screen and interact with security-relevant apps or websites.

The best option is therefore to extend the time limit shortly before it expires by simply interacting.

However, it is necessary that the base time is sufficient. Some banks give you just three minutes, which is probably too short even for some non-disabled people.

I was very surprised that the WCAG does not require that the time limit is actually displayed in this mandatory criterion. The responsible body WAI really messed up there.

SC 2.2.6 - Timeouts (Level AAA)

This AAA criterion is not mandatory.

Users must be informed of the following:

Existence of the timeout: The page must make it clear that a timeout exists.
Duration of the timeout: It must be stated how long the user has before a timeout occurs.
Impact of the timeout: What happens when the timeout expires? E.g. whether data will be lost.

The following differences exist between the two criteria:

• 2.2.1: Allows users to actively control time limits.

• 2.2.6: Only provides information about the timeout, without necessarily control over it.

Accessibility level:

• 2.2.1: Level A (basic accessibility).

• 2.2.6: Level AAA (higher accessibility).

Commitment to adaptability:

• 2.2.1: Requires that users can adjust the timeout.

• 2.2.6: No obligation to adjust, just for information.

I'll leave it as it is without comment. In my view, displaying the elapsed time AND controlling the time is necessary. Without information about the time still available, you cannot assess whether you can complete a complex process. For example, banking applications do not interpret every interaction, but only those such as submitting a form as an interaction. This means that reading the transactions by scrolling through the table as a client-side process does not usually count as an interaction.

What are exceptions?

Exceptions are allowed where the time limits are fundamental, an example being auctions. Online exams are also likely to fall into this category. An extension due to disability is requested administratively and only carried out in the application, but not initiated by the examinee themselves.

The PST 3 problem

PST 3 applies specifically to Banks in the European Union, a regulation that is intended to ensure greater security in online banking. It requires uniform security measures such as two-factor authentication or automatic logout in the event of inactivity. This period should be no more than five minutes.

Five minutes is a very short time for disabled people. There are major challenges when entering complex data such as IBANs, which then have to be checked for correct transmission. Last but not least, reading account tables can also take longer. Yes, there are professionals who can do this quickly thanks to the high speed of the voice output. However, this is not possible for many blind people due to their rather slow working methods or the use of the Braille display. Time limits are usually not calculated via the client: This means that scrolling or unfolding an accordion does not usually lead to an extension, only calling up a new page resets the timer. In my opinion, this would also be a starting point for safely extending the time period.

Using two-factor authentication can also take significantly longer than the permitted time period. In my experience, it is a few seconds between the trigger, i.e. the first factor, and the confirmation, i.e. the second factor.

Logging out without losing data and continuing where you left off is also permitted. This means that if you are in a process, you should be able to continue where you left off and not have to start again from the beginning. An example is a form sequence that you should be able to continue where you left off without losing any information you have already entered. Howecer you eed JavaScript for the forms and most Bankings seems to work with Server side processes.

Make timers accessible for the Disabled

In my opinion, the timer should always be placed as high up as possible and in any case before the relevant content (WCAG requirement Meaningful sequence. It should have its own ARIA region so that it can be found quickly. The timer itself should not be in a live region, as information that is output too often disrupts the speech output.

The mechanism for extending shortly before the expiration must be easy to find and activate. A dialog that is integrated as a focus trap is a good idea. After confirmation, the focus should return to the element where it was before the dialog was opened.