john Gill technology header image

Adapting User Interfaces to Suit Individual Needs

John Gill

Increasingly there is a need to personalise one’s interactions with a device or terminal.  This facility is often provided on personal devices but rarely provided on public terminals such as cash dispensers.  Two projects, one in the UK and one European, have recently started which address this problem.  The European project ( is concentrating on ATMs and ticket machines at railway stations whereas the UK project is piloting survey terminals and computer accessibility in public libraries (



Over the next few years one will need to be able to operate a range of self-service terminals to obtain access to goods and services.  This will include ticket machines for public transport, information terminals, and cash dispensers (ATMs).  In addition there will be terminals shared between a number of users; these include computers in schools and universities as well as television systems.

These terminals tend to be designed for a ‘typical’ user but have to be used by people with a wide range of abilities.  Therefore the ability to customise the terminal to suit an individual’s needs would make the terminals usable by a wider range of people; consider a foreign visitor might want the terminal to display information in their language.

Approximate proportion of the population who experience difficulties in using public terminals
(NB Do not aggregate the figures since multiple impairments are common)

0.4%        Wheelchair users                                 1%           Dyslexic
5%            Cannot walk without an aid                3%           Intellectually impaired
2.8%        Reduced strength                                                0.1%       Deaf
1.4%        Reduced co-ordination                       6%           Hard of hearing
0.25%      Speech impaired                                  0.4%       Blind
0.6%        Language impaired                              1.5%       Low vision


The coding of user requirements can be held on the card, or other smart medium, which is carried by the user; the card could be contact or contactless.  Another possibility is for the card to hold the customer's account number, and the coding to be stored in the network.  A third method is for the user to log-in to a system and then the coding is retrieved from their profile file; this approach may be the most appropriate for hot desking environments.  These requirements would only be stored at the user’s request.

An important aspect is that the user should have the ability to change their preferences.  In some cases this may be done directly on the terminal, but in other scenarios it could be done indirectly via a web site (and then updated when they next use a terminal - as is already deployed for adding credit to a pre-pay Oyster card).  An example of this is at

Consider a lady with poor vision who wants to purchase some DVDs as Christmas presents for her grandchildren. She knows she can obtain them cheaper on the internet but she does not have a computer at home. So she goes to the public library to use one of their terminals. However the librarian finds it time consuming to set the computer terminal to give appropriate size of icons and text to suit the customer's needs.

However her special needs could have been stored on her library card. She just inserts the card into the computer terminal, and it automatically adjusts the size of icons and text, the colours and type of cursor to suit her needs. When she has finished her session, she removes the library card, and the computer automatically reverts to its normal settings. If she wants to change any of her special needs settings, this can be done on the terminal and stored back on her library card.

The work on developing a system for coding these user requirements has been completed and it is a formal European and British standard.  This coding system has been incorporated in the ITSO specification for smart card ticketing for public transport in the UK.  The standard is also recommended in eGIF, published by the Cabinet Office, for all new cards issued by government departments, local government or any agency of government.

The software to reconfigure Microsoft Office has already been developed.  In this case all the accessibility options associated with Windows XP can be coded on the card, and the system returns to its default settings as soon as the card is removed from the reader.

For adaptable user interfaces to be widely adopted, it is necessary to develop user friendly software and validate this software in a range of application areas.  It is also necessary to disseminate best practice amongst the stakeholders.  The Snapi project has been set up to undertake these tasks.

Application Areas

In principle, the concept of adaptable user interfaces can be applied to a very wide range of terminals.  This section describes five areas identified as potential early adopters of this approach.

In England, from April 2008 all persons over 60 and people registered as disabled were entitled to free use of buses after 9.30 am (Scotland and Wales already had similar systems in place).  The Department of Transport specified that the concession passes must be contactless smart cards in accordance to the ITSO specification.  This specification already permits the coding of user requirements.  In addition all new rail franchises are required to implement ITSO ticketing.

The coding on the card could be used to request larger characters on a screen, speech output from a visual display or more time to go through automatic gates.  There is the potential of making real-time passenger information systems, at stations or on board the vehicle, accessible by people with visual impairments.

The EMV (Europay/Mastercard/Visa) specification for cards does not allow for coding according to EN 1332-4.  However it is possible, on multi-application cards, for the coding to be treated as a separate application.  Thus, on terminals such as ATMs, the user could choose for the display to have larger characters with a choice of colours for the text on an uncluttered background, and to use the keypad instead of the touchscreen.

In the foreseeable future there is likely to be a significant increase in non-contact payment systems for low value transactions.  The Snapi coding could permit users to select appropriate feedback; for instance someone who is deaf might want visual feedback to indicate a successful or failed transaction.

In this application the user preference card would permit a special needs user to simply select their preferences (eg subtitles with a specified transparency or audio description), and re-set to default options for other members of the household.  Such a system could also be beneficial in hotels so that the guest can easily obtain their preferred mode even though they were not familiar with that model of television set.

More sophistication could be incorporated when interactive television services (eg home shopping in a similar style to web-based services) become more widely available.  The coding allows for facilities such as restructuring menus so that they can be selected by number rather than by highlighting the relevant item.

Since all integrated digital televisions in Europe are required to be fitted with a Common Interface (CI), and some set top boxes are also similarly fitted, the CI socket could provide the route for inserting a Snapi card into digital TV receivers, via a simple card reader that fits into the CI slot.

Government and Local Government
For systems which are on-line, it may be possible to include the customer's account number on the card, and store the coding of the preferences in the network.  For off-line systems, the coding will need to be on the card.

In libraries it is common to have internet access which can be used by people who do have internet access at home.  Librarians do not always have the time or skills to reconfigure the computer terminal to suit each client (and to reset it before the next user).  The Snapi approach means that the user’s library card can quickly set the computer to the user’s needs and automatically reset the computer for the next user.

In sports centres it is common to hand over one’s membership card at the reception desk.  The card is then inserted in a reader and the receptionist is given a display relating to that client’s booking.  The Snapi approach would permit a user to add a message to be displayed on the screen (eg “Please look at me when speaking”).

For access control, the card could provide additional feedback; for instance it could provide a visual signal to indicate that the door is now unlocked.

Hot Desking
In schools, universities and some offices users are expected to use any available terminal.  For these systems, the user will usually input their username and password to access the system.  Therefore the coding could be stored in the network and activated as soon as the user has logged into the system.


The Coding System

The European standard EN 1332-4 permits a wide range of preferences to be coded.  However the standard also allows the coding system to be quickly and easily extended.

The basic coding allows for:
Input requirements – Specifies whether data input should be voice input, keyboard input, special keyboard or wireless
Keyboard characteristics – Specifies whether the numeric keypad should have a top row of 1,2,3 or 7,8,9, whether the alphanumeric layout should be qwerty or azerty or alphabetic
Position of input devices – Specifies the height of a data input device above floor level
Character size – Specifies the height of characters in millimetres.
Font – Specifies whether no moving or flashing text, the use of serif or sans-serif font, and whether the font should be mono-spaced
Icons – Specifies whether icons should be enlarged, have increased contrast, have a text description, use default or specified colours
Screen colour – Preferred colours for the presentation of visual information
Colour avoidance – Specifies specific colours or combinations of colours to be avoided when displaying visual information
Language – Specifies up to four preferred languages in order of user preference
Symbols – Specifies whether text, symbols, sign language or Braille is required.
Screen position – Specifies the height of the screen above floor level
Speech output – Specifies whether audio output should be on loudspeaker, headset or hearing aid (via inductive coupling)
Speech rate – Specifies preferred speech output rate in words per minute
Sound amplification – Specifies the level of sound amplification from the terminal in dBA
High frequency amplification – Specifies the amplification above 1 kHz
Low frequency amplification – Specifies the amplification below 1 kHz
SMS – Specifies whether SMS input or output required
On-screen keyboard – Specifies whether the on-screen keyboard should be standard, enhanced, have regular or block layout, use 101, 102 or 106 keys
Non-keyboard input – Specifies whether voice input should be letter-by-letter or words or natural language, whether there should be feedback on voice input and whether a pointing device should be used
Touch screen – Specifies whether large button or very large button size required, whether system operation should be from finger entering or exiting touch-sensitive area
Time-outs – Specifies the additional time to complete user input processes
Interface complexity level – Specifies the level of complexity for dialogue or text presented to the user as simplified or very simplified dialogue, simplified or very simplified text, low or very low text density
Screen reader - Specifies whether to use the default or some other screen reader, whether to announce events on screen, whether to produce speech output of input characters as they are typed, whether to move mouse pointer to the active item, and whether to start with the narrator minimised
Links – Specifies whether audio output for links is spoken, in different voice or a sound effect
Screen enhancement software – Specifies whether to use default or other magnifying software, whether to follow the cursor, whether to follow keyboard focus, whether to follow text editing, and the level of magnification
Pointer buttons – Specifies whether to switch between primary and secondary buttons, the double-click speed and whether to turn on ClickLock
Pointer characteristics – Specifies the pointer speed, and whether the pointer should snap to, display pointer trails, hide pointer while typing, show location when designated key is pressed and whether to use the keypad to move the pointer
Numeric, time and date presentation – Specifies whether the decimal point should be represented by a comma, period or space, whether to use 12 or 24 hour clock, and whether the date should be in day, month, year or month, day, year format
ALT text – Specifies whether the ALT text should be spoken
Speech output of non-alphanumeric characters – Specifies whether the tabs, punctuation and buttons should be spoken
Braille display – Specifies whether to use Grade 1 or 2 Braille, 6 or 8 dot cells, and the types of text to mark
Captions – Specifies the speed of presentation, the level of veiling and whether enhanced captions should be used
Audio description – Specifies the level of description
Clean audio – Specifies whether to omit background music and non-essential noise
Menu selection mode – Specifies whether to select menu item by highlight or from a numbered list
Scrolling mode – Specifies whether to use scrolling wheel, up/down buttons, left/right buttons, and speed of scrolling
Animation – Specifies animation speed
Biometric characteristics – Specifies which biometric characteristics cannot be used
Visible output of audible prompts – Specifies preferred settings for the visual signal generated to indicate an audible prompt
Duration of visual signal – Specifies the duration of the visual signal when an application generates a sound
Pre-stored message – Specifies a pre-stored message to be displayed on an assistant’s screen
Variable message – Specifies that a message stored on the card is displayed on an assistant’s screen
Application specific requirements – Specifies a set of user requirements which are specific to the application being implemented


Project Outcomes

The UK project expects to have two demonstrators operational this year, and hopes that further roll-out will happen soon afterwards.  The European project is more ambitious but is planned to last for three years.



John Gill Technology Limited Footer
John Gill Technology Limited Footer