Accessible mobile interfaces

Funka have designed and published a set of guidelines for developing of accessible mobile interfaces (in Swedish).

Funkas methodology was developed in close collaboration with the disability movement and all that we recommend is tested in reality. Our business is based on international guidelines for accessibility, Web Content Accessibility Guidelines 2.0 (WCAG 2.0). Funkas long experience of the availability of work and testing with users with different needs and conditions, with and without aids, shows that WCAG 2.0 is not enough. We have therefore developed the test criteria for points that are complementary to international regulations and the public sector through the EU decision to follow.

This is very relevant to my thesis even though Feide, which is an internal system for students and people in the educational sector, not is affected by the EU regulations, it is a technology used by more and more people and should ideally be accessible to everyone.

The guidelines is 48 points divided into six categories. I have tried to translate it to English and sum up the important parts.

Choice of solution

• Make sure that your website works on mobile devices
  • keep it as simple as possible and make all content available.
•  Offer a mobile solution if your website are large or complex, but don’t force it in the user.
  • link between the different sites.
• A mobile solution of your website should offer the same information and services unless it have been specified that it is a limited section of the site.
• Create apps for for well defined features that users need to access frequently.

Construction

• Use WCAG 2.0, except when we tell you not to!
  • WCAG 2.0 is for developed for web interfaces and will apply for apps in some cases as well. However marking of non-text objects and contrast
• Follow the devices design and accessibility guidelines and the  and platforms conventions unless these guidelines tell you otherwise.
  • etc. are you designing for Apple, follow their guidelines for iPhone.
• Describe graphical elements like icons and buttons («alt-text»).
  • How you do this varies between different operative systems.
• Label or describe form objects (text fields, radio buttons, check boxes) as good as possible.
  • Tips. Use the form objects title-text for this if the label is not enough.
  • The instructions have to be visible on the site, because the title-text will not be visible to users without screen readers
• Avoid frames and iframes in web interfaces as they perform poorly on many mobiles.
  • If you have to use an iframe, make sure you also offer a link for the user to see the content in a new tab without frames.
• Help the user by adapting the keyboard to the expected input.
  • Use HTML5 to mark input fields in web interfaces – phone number, e-mail, or text.
• Don’t use many scripts as this can cause problems with the performance of the phone.
• Always conduct tests with people that have not participated in the developing.
  • One should always include test persons with disabilities and let accessibility experts interpret the result.

Layout and design

• Place important things higher up and less important things lower in scrolling views.
• Group things that belongs together.
  • extra important to do in responsive design.
• Strive to create a clean design and minimize the number of unnecessary objects.
• Minimize the header to avoid a lot of scrolling.
• Create large click surfaces
  • Strive to create a click surface with the length of the body in one direction and the body row height X 3 the other direction.
  • an icon in an app should be at least 9 x 9 mm
• Buttons that are frequently used should not be placed by the left or right edge of the screen if it does not occupy at least one third of the screen width.
• Do not right align buttons, functions or groups of them unless they cover at least 75% of the screen
• Place links and buttons on clear rows (horizontal or vertical) to make it easier to find the buttons.
• Prompts for input fields should be placed over the field
  • except with radio buttons and check boxes
• The row length should be adapted to the screen length, but should include no more then 70 signs including spaces.
  • Try to not exceed 55-60 signs including space on each row.
• Limit the amount of information and numbers displayed.
  • You don’t have to remove parts, but you can use a so-called accordion functionality (clicking on a title to precipitate the underlying data).
  • You can also add menus and link groups in precipitating menus.
  • Note that the functionality must be clear, it should be intuitive for the user to get the hidden parts.
• Use familiar icons
• Clickable objects should look clickable.
• Use high contrast
  • bread text and text for icons  should be presented with black text on white background or opposite, if the text is not large of can be zoomed.
  • for large text or text that can be zoomed see WCAG 2.0 – 1.4.6
• It should be possible to use the interface with the phone lying both horizontally and vertically.

Interaction

• Use simple navigation concepts.
  • Menus needs to be designed so that they take little space and offers a visually clear presentation.
• The buttons in the hardware should be enabled for navigation in the interface.
  • etc. the back and menu-buttons on Android.
• Interfaces for devices that can be connected to a keyboard should also to a great extent could be controlled only with a keyboard.
• Add shortcuts to jump between content on long pages
• Minimize text input
  • use lists of choices and «auto complete»
• If the interface allows gestures, this should be enabled.
  • etc. drag your finger across the screen to scroll between pages on a iPad.
  • gestures should be intuitive and consistent.
  • use gestures people are used to.
• Don’t add functions that only can be controlled by gestures
  • supplemented with a button or a link
• Make it possible to control the interface with only one finger
• Be consistent
  • add buttons with the same functionality in the same place and add the same design.
• Use built-in objects as they are supposed to be used.
  • can be used instead of create and implement new once.
• Give feedback to the users input
  • but also allow the user to regulate the amount of feedback
• Give the user status information
  • visual feedback and feedback with sound is an advantage
  • etc. it the site is loading, give feedback about this
• Give the user time enough time and warnings before the time limit is reached
  • etc. before you are automatically logged out
• Help the user to avoid mistakes and correct errors
  • communicate errors to the user and propose solutions if possible
  • etc. auto complete

Contents

• Only use images if it really helps the user.
  • minimize the use of images for decoration, if you need to use them place them in the CSS-code.
• Use short but descriptive headings to structure the information
• Avoid abbreviations
  • abbreviations for organizations or similar can be used if it is explained the first time it is used.

User Preferences

• Make sure you can zoom the interface
• Consider providing a setting to invert the colors
  • etc. the user should be able to switch so that it instead is light text on dark background, and show-versa.
• Consider providing a setting to change font

Here you can read the complete set of guidelines for developing of accessible mobile interfaces in Swedish.