Paul
Age: 19 years
Course: Computer Science 1st Year
Hobbies: Rugby, travelling, films and social life
Background:
Paul really struggled at primary school and never enjoyed writing with endless corrections and not being very dextrous when it came to cursive script. Eventually his difficulties with literacy skills were assessed and he received some extra help, but he never really talked about his dyslexia and was anxious about the mistakes he made, even though he knew his father had had similar difficulties and ran his own very successful IT company. However, Paul soon discovered he was in a very different situation on the sports field and any lack of coordination seemed to disappear with the local youth rugby team giving him a chance to shine. He not only captained the side during his sixth form years, but went on to join the university team in his first year and immediately found friends that allowed him to work around his lack of confidence, when it came to the academic side of things.
Paul not only realised there were others who had similar difficulties with course work and lecture notes. He also requested extra time to complete written tasks and the use of a laptop as neat handwriting and getting ideas down on paper remained a challenge. Choosing a science degree made it easier as it fitted with Paul’s strengths. When it came to problem solving, he found he could visualise the whole thing and often see a solution rather quicker than some other students, who took a linear path. Now Paul openly admits that in his rush to get down his ideas he may make copying and spelling errors and his memory and organisational skills can let him down. However, he has also learnt a range of strategies built up over time, such as downloading reminder, task and password apps onto his mobile phone. He uses computer applications that auto-correct and read text aloud, plus looking out for supportive tools that highlight errors when compiling code and making use of graphical interfaces for system and software design. Paul’s father is an IT systems analyst and computers have always been part of his life.
Once Paul has a concept firmly in his mind, good analytical skills have meant that he can discuss possible algorithms or practical ways to get something to work. He really enjoys projects and working with a group, as this allows him time to bring his abilities to the fore, whilst letting others do the report writing and documentation!
Strategies to overcome Barriers to Access
Multifactor authentication is a challenge especially when copying or remembering passwords is a necessity. Paul uses the required Microsoft Authentication app for university logins but he largely depends on biometric logins (Android code) or secure second-factor authentication without SMS texts where possible (these are beginning to appear on the web services). He understands the need for secure VPN requirements when working from home and has set up a password manager as advised by the National Cyber Security Office . He also has several rules to help filter spam emails on an Outlook account.
When coding he has considered the Web Content Accessibility Guidelines (WCAG) 2.2 Success Criterion 3.3.7 Accessible Authentication as they have the potential to make developers aware of the issues for those who have different types of cognitive impairment including dyslexia.
Keyboard Access is important for Paul as he often uses keyboard shortcuts when writing code having learnt these over time. He also finds it helpful when considering speech recognition whilst developing websites, as access and navigation can be made much easier (W3C WAI links for keyboard access related to Speech Recognition).
Consistent Navigation (WCAG) and Heading order (Webaim) helps Paul follow the flow of a web site. Clear, well-structured and easy to use menus that are consistent on every page are as much about usability as they are accessibility and the size of the headings with bold text can indicate the importance of content that needs to be read.
Form Fields and Instructions (WCAG) Guidance and clear indicators of what is needed in form fields can enhance completion rates and prevent errors. Labels need to be near the edit areas (G162: Positioning labels to maximize predictability of relationships)
Error Identification (WCAG) Any errors that are made should be flagged up with helpful correction notices that do not just depend on colour or cryptic messages. The latter can often occur when a login is required and the user is none the wiser as to what is missing or incorrect. At all times error messages must be able to be read aloud with text to speech and be informative. Mozilla show how an ARIA alert role can be used when a ‘session is due to expire or connection to the server fails’.
Selectable text for speech output – This is not quite the same as screen reading, where navigational elements as well as content are read aloud. Paul likes to choose when he wants to highlight text and have it read out. He can do this easily on his mobile phone with text messages, but finds on some websites and with certain PDFs that text may not be accessible. Google calls this ‘select to speak’. It is important to be wary about making text just available for screen readers. You may present barriers to other users, so make sure visible text can highlighted by keyboard or mouse use when testing for accessibility.
Control over look and feel of a web service This can involve customisation as well as personalisation Paul usually adapts the user interface to suit his needs, as well as being able to select different settings in applications. He sometimes wants to have an overlay to reduce the glare of black on white text and often changes font sizes and styles plus line spacing so these need to be adaptable. He turns off any animated or timed elements and will stop blinking or scrolling text, as he finds this much harder to read. He also does not like moving backgrounds or animated non-text elements that cause distractions. An example of a site that is known for these issues is Lingscars . WCAG Success Criterion 2.2.2 Pause, Stop, Hide (Level A)
Document accessibility is important for everyone and when Paul uses his text to speech apps he expects to be able to have content read aloud at any speed in an order that makes sense, with a voice of his choice. WebAim have an easy to follow set of instructions for making ‘Accessible Documents: Word, PowerPoint, & Acrobat’.
Key points from Paul
“I like to understand what a web site or service is about immediately! If it is cluttered and I have to navigate through several layers to get to content I give up. Keep it simple is a good motto for me because I am impatient and don’t want to read long introductions. Just give me a one liner and a diagram or picture that says it all!”
If you have a moment think about reading “Making Content Usable for People with Cognitive and Learning Disabilities” (W3C Editor’s Draft 21 September 2021) where the authors have provided a design guide that includes eight objectives namely:
- Help users understand what things are and how to use them
- Help users find what they need
- Use clear and understandable content
- Help users avoid mistakes and know how to correct them
- Help users focus
- Ensure processes do not rely on memory
- Provide help and support
- Support adaptation and personalization
Paul Crichton 2019 on UserZoom “Five ways to make your digital content easier to use and understand for people with dyslexia. ”How to make better websites for people with dyslexia“
Professor Stein’s article on the BCS website, The Chartered Institute for IT Why dyslexics make good coders