As this project draws to a close and I meet my deadline, I’ve decided to carry out an Accessibility Audit, which will also inform the app’s Accessibility Statement and future development (potentially in my next module). For public sector bodies (such as the University of Winchester), the requirement to make applications and websites “perceivable, operable, understandable and robust” is mandated by the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018, brought about in September 2018. It is possible that the app may not need to adhere to these regulations. The UK Government state: “mobile apps for specifically defined groups like employees or students are not covered by the regulations,” however, completing an accessibility audit will be a good learning experience for me and will highlight areas for improvement that could be implemented in my next module, DM7903 Design Practice (Government Digital Service, 2018).
An Accessibility Audit would usually be carried out by an external, trained professional, as this would ensure high quality and impartial assessment against the “WCAG 2.1 AA accessibility standards”. In the interests of my learning journey, I will be completing this audit myself and recording my thoughts.
Principle 1: Perceivable
To meet WCAG 2.1 Principle 1: Perceivable you need to make sure users can recognise and use your service with the senses that are available to them.
This means you need to do things like:
- provide text alternatives (‘alt text’) for non-text content
- provide transcripts for audio and video
- provide captions for video
- make sure content is structured logically and can be navigated and read by a screen reader – this also helps if stylesheets are disabled
- use the proper markup for every feature (for example, forms and data tables), so the relationships between content are defined properly
- not use colour as the only way to explain or distinguish something
- use text colours that show up clearly against the background colour
- make sure every feature can be used when text size is increased by 200% and that content reflows to a single column when it’s increased by 400%
- not use images of text
- make sure your service is responsive – for example to the user’s device, page orientation and font size they like to use
- make sure your service works well with assistive technologies – for example, important messages are marked up in a way that the screen readers knows they’re important
Principle 2: Operable
To meet WCAG 2.1 Principle 2: Operable, you have to make sure users can find and use your content, regardless of how they choose to access it (for example, using a keyboard or voice commands). This means you need to do things like:
- make sure everything works for keyboard-only users
- let people play, pause and stop any moving content
- not use blinking or flashing content – or let the user disable animations
- provide a ‘skip to content’ link
- use descriptive titles for pages and frames
- make sure users can move through content in a way that makes sense
- use descriptive links so users know where a link will take them, or what downloadable linked content is
- use meaningful headings and labels, making sure that any accessible labels match or closely resemble the label you’re using in the interface
- make it easy for keyboard users to see the item their keyboard or assistive technology is currently focused on – this is known as ‘active focus’
- only use things like mouse events or dynamic interactions (like swiping or pinching) when they’re strictly necessary – or let the user disable them and interact with the interface in a different way
- make it easy for users to disable and change shortcut keys
Principle 3: Understandable
To meet WCAG 2.1 Principle 3: Understandable, you have to make sure people can understand your content and how the service works. This means you need to do things like:
- use plain English
- keep sentences short
- not use words and phrases that people won’t recognise – or provide an explanation if you can’t avoid it
- explain all abbreviations and acronyms, unless they are well known and in common use – for example UK, EU, VAT
- make it clear what language the content is written in, and indicate if this changes
- make sure features look consistent and behave in predictable ways
- make sure all form fields have visible and meaningful labels – and that they’re marked up properly
- make it easy for people to identify and correct errors in forms – you can find best practice for form design in the GOV.UK Design System
Principle 4: Robust
To meet WCAG 2.1 Principle 4: Robust, you must make sure your content can be interpreted reliably by a wide variety of user agents (including reasonably outdated, current and anticipated browsers and assistive technologies). This means you need to do things like:
- use valid HTML so user agents, including assistive technologies, can accurately interpret and parse content
- make sure your code lets assistive technologies know what every user interface component is for, what state it’s currently in and if it changes
- make sure important status messages or modal dialogs are marked up in a way that informs user of their presence and purpose, and lets them interact with them using their assistive technology
- lets the user return to what they were doing after they’ve interacted with the status message or modal input
Thoughts
As there are many criteria within each part of the audit I have decided to summarise them separately below:
Principle 1 – I believe that the content within my prototype’s is structured logically and is screen reader friendly because no text is placed as images. The fact that tab-bar elements are labelled also means that they can be read by a screen reader. I have not used colour as my only way of conveying meaning, and in most cases text has a high colour contrast ratio with its background (and the Dark Mode further improves upon this). Two key improvements that could increase accessibility in this area would be to plan for responsive resizing to adapt to uses different devices, and to allow text size to be increased by up to 400%. Both of these features would help visually impaired users, and would require me to make challenging adaptations to the layouts within my prototypes. This could be a great starting point for my next module.
Principle 2- Many criteria in this area address keyboard usage, which is not strictly relevant for my application. However, by including a toggle for a “reduced animation mode” I could limit the animations caused by gestures/interactions – this functionality is not yet active in any prototypes.
I have met the criteria in at least two areas though – Firstly by using descriptive titles for each screen within the app, and by repeatedly testing the information architecture I have proven that the app allows “users to move through content in a way that makes sense”.
Principle 3 – My prototype’s have allowed me to make plenty of progress in this area. The textual information within the prototype is it written in plain English and does not include long sentences. TV studio specific terminology is kept to a minimum while there are no niche abbreviations or acronyms present. In working alongside Apple’s Human Interface Design Guidelines, I believe that features are consistent with iOS and behave in predictable ways.
I have not been abundantly clear about which language the app’s content is written in, however in reality I believe that an assumption might be made by users who use either the Apple App Store or Google play store – I would expect them to assume that applications available in their region will accommodate for the most commonly spoken languages of that region. This is an area for me to do some further research.
Principle 4 – Due to the nature of my skillset and prototypes, I have not needed to write code for this module. However, I have achieved one of the criteria in this area: When a user is shown a system alert (due to pressing the “help” button), they are able to read the alert text and then press the “Okay” button to dismiss the alert and continue their task.
The UK Government (2016). Making Your Service accessible: an Introduction. [online] Gov.uk. Available at: https://www.gov.uk/service-manual/helping-people-to-use-your-service/making-your-service-accessible-an-introduction#what-to-do-in-alpha [Accessed 22 Jul. 2021].