Rather like I did for the 3,000 word report about evaluating successful user-centred design earlier on the year and like I do for my project work, I thought it’d be a good idea to start doing reflective journal-esque posts about my dissertation to record my thoughts and progress on the report proposal.

March 2019 – coming up with an initial idea, then changing it

My first dissertation idea is mentioned in this blog post from March 5th. The idea originally was to research and write about how ‘apps that save consumers time put pressure on those working to deliver’, using Deliveroo and Amazon as good examples of companies well-known for exploiting their workers to enable them to meet unrealistic customer expectations about things like delivery times and costs. It’s a topic that has interested me for a while, but upon discussions with Jamie on March 26th and attempting to research the ‘gig economy’ (as it is known), by April 2nd I decided that writing about this from a UX perspective was too difficult. You can read my initial thoughts in much more detail in the blog post linked above.

Report Proposal session – March 28th 2019

On March 28th I attended an hours’ seminar with Aaron, a Games Development Tutor, to learn more about the Report Proposal. Aaron delivered an excellent presentation and covered how to pick a topic to research, how to come up with a question and what each section of the proposal should include.

In short:

• The question needs to be interesting, related to a target audience or user group, concise and ‘defined’.
• The question can then be used to help with research and finding sources.
• If the question is clear, niche, complex, inspires you to write the dissertation and focused then it is a good thesis question.
• The report proposal should be in the format of introduction, literature review, methodology, aims and objectives of the report and finally a section about limitations.

This is what each section should aim to achieve:

• Introduction: define some key terms, explore some broad topics around the question, explain what the topic is and give a basic understanding of it.
• Literature review: this should consume about 500 of the total 1,000 words for the proposal and explain how your research fits into the broader scope, list 5-7 sources that you might use, review some research that has already been done and provide an opportunity to make a good argument to justify the need for you to research further.
• Methodology: for technical reports really, but this is where you’d justify your choice of methodology if you were running an experiment, reference existing quantitative research, explain your data collection method and also explain how your method is used.
• Aims and objectives: simply assess what the issues are that are being explored, what are the questions that will be answered and what I want to achieve from writing this report.
• Limitations: should include information about possible limitations that might make the report not as accurate as it could be, such as time, costs and things like that.
• Conclusion: optional on this proposal, but is a good place to list limitations and summarise the report.

The report needs to be 1,000 words long and will be submitted on May 10th with the rest of BSc2b.

Early April 2019 – coming up with a new idea

Between March 28th and April 2nd 2019 I decided to change the idea and I am now going to write about how UX and technology can help improve the accessibility of digital services. This is something that has interested me for a while. When I was a Microsoft Student Ambassador, I remember being asked to trial a beta version of OneNote Learning Tools, aimed at improving the accessibility of OneNote for dyslexic users and since then have been interested in software accessibility. At BETT 2019 I presented on the Microsoft Education UK stage all about new accessibility features in Microsoft OneNote and how they can help students.

I thought that there would be a lot of research available to look at around software accessibility – or certainly a lot more than the impact of employees in the gig economy from a UX perspective – so this seemed like a much better option for my dissertation.

I presented the idea to Jamie on April 2nd and the idea went down well. We discussed how this would need to be focused around one technology or one user group/disability (e.g. focusing on how voice/sound helps improves accessibility across several disabilities or focusing on what can be done to help improve software accessibility for the partially-sighted or blind) to ensure that it has a clear focus. At the moment I am particularly interested in how audio and voice control and/or sounds can help improve accessibility for the blind, partially sighted or cognitively disabled people.

I caught up with my former boss, Kevin Sait (whom I presented with at the BETT Show in 2019) on April 7th and we got onto the discussion of my dissertation. He suggested that I took a look at some iOS apps made by Microsoft called Seeing AI and Soundscape that are designed to help those who are partially-sighted or have cognitive disorders by telling them what is in their surroundings to make them more aware of what is around them.

April 15th 2019 – Microsoft Seeing AI

I spent several weeks working on the Broads project, but after that was done I arranged to borrow an iPhone 7 from university for two weeks over the Easter holiday to experiment with the Microsoft Seeing AI and Microsoft Soundscape apps on it. These apps are to help partially-sighted and blind people identity what’s around them. Look at the video demo of Seeing AI that I recorded below – it’s using the camera on the phone to scan the surroundings and tell me what it is seeing!

My father is 51 and I am 21 – you can see how close Seeing AI got to guessing our ages correctly! As mentioned by myself in the video, a few years ago Microsoft made a website where you could upload a photograph of yourself and it’d try to guess your age. We’re now seeing the results of this in these apps.

April 16th 2019 – research begins

What is meant by research?

Research in higher reducation is like research in the ‘everyday sense’ (Cottrell, 2014, p. 20). We research things that we are:

• Interested in and want to know more about.
• Find information about.
• Interested in making sense of.

Generally, research begins with a question and an investigation and finishes with a result.

Research in higher education is more significant, systematic, more informed and should contribute to existing knowledge. It should also be evidence-based, clearly communicated and be built on academic integrity (Cottrell, 2014, p. 20).

It’s also important that research is objective-based rather than opinion-based – writing a dissertation on something that you have pre-formed strong ideas about will be very difficult as you will have a persional bias (Cottrell, 2014, p. 20).

Beginning my own research

Today was really the first day where I dedicated a good amount of time to researching the dissertation.

Armed with a new topic to research, I went into university to research good design principles for those who are partially sighted or blind. I found a lot of ‘blog-type’ articles on Medium and other sites all about the sort of things that web designers should be doing to help improve accessibility, many of these articles referencing the WCAG 2.0 and WCAG 2.1 web accessibility standards (defined by W3C) to justify why the use of utilising the ‘alt’ tags on HTML elements for narration software and ensuring that the keyboard could be used for navigation is good for accessibility. Other common conventions were:

• Consider colour-blind users and the use of colours. Some colours are difficult for them to see – use software to mimic colour-blindness to test your designs and also conduct usability testing with colour-blind people.
• Use meaningful micro-copy – labeling every button ‘Click here!’ is not good for those using text-to-speech software as the same button text will appear on multiple buttons and this will make it hard for them to understand what the button is actually for.
• Likewise, ensure that page headings are descriptive and informative.
• Ensure that navigation remains consistent and repeated components appear in the same order on each page.
• Don’t rely on device-dependent interactions, such as ‘hover’ which only works on desktop computers. Try to ensure that interactions can work all kinds of devices.
• Ensure that touch targets are at least 9mm x 9mm in size.
• Create content that can be presented in ‘cleaner’ and more ‘logical’ layouts (such as a single block of text as opposed to text broken with images).

With this in mind, I went onto some online tech journals to see if any research had been carried out about the best practices for designing for those with visual impairments. I found some interesting pieces about creating smartphone apps for blind photographers and the ‘UX challenges of a voice control mobile app for the disabled’ as well as a piece about ‘how users overcome obstacles in voice UIs’ on ACM, as well as reports written about improving educational software for students (notably geometry software which when coupled with a tablet computer and some hardware makes drawing shapes easier for visually impaired children), but I left university today feeling a tiny bit confused. I wasn’t sure if I had found the right things or not. Some of the academic journals I was looking at were written as recently as 2018, some as long ago as 1997. I thought about using the references in those journals as my own sources, but thought it might be hard to acquire the books that had been used to write those journals.

And I still didn’t have a question.

How to create a dissertation question

Starting simple is the best thing to do, if you can’t start simple then maybe you don’t really know what it is that you want to research (Cottrell, 2014, p. 75). Perhaps I was a bit unsure at this stage about what it was that I wanted to focus on.

A good title is?

• Clear – makes sense to the reader.
• Specific – sets the parameters of what the research will address.
• Incorporates a question that the research aims to answer.
• Is precise – the question is short and clear.
• Fits conventions – is typical of previous titles.

Subtitles can also be used to make a controversial or eye-catching title appear more ‘grounded’ (Cottrell, 2014, p. 75). For example:

‘Too litte, too late.’ An analysis of the failure of local government interventions to improve levels of water pollution in New Acid Town, 1986-95.

That’s an example from the book about dissertations I am reading. It’s not relevant to my subject, but shows how ‘subtitles’ can be used to counteract an opinion which can draw the reader in to read your report.

Advice from a friend!

Tonight I had a call with a friend of mine called Callum Brown, whom is in Year 3 at the moment so went through this last year. I told him that simply reading around the subject hand’t helped me to come up with a question to research as yet. He suggested that I take some time to brainstorm ideas around the subjects that I am researching, notably brainstorm ideas around ‘visually impairments’ and ‘accessibility’. He suggested that specifically I brainstorm ideas relating to case studies, statistics and website design around those two subjects. He mentioned that brainstorming ideas and researching the UI languages for the visually impaired, the design of hardware for the visually impaired and even how developers make these design languages work with the hardware would also be a good starting point.

From there, he suggested that this would give me a good idea of the broad scope of the subject and that ‘connecting the dots’ would probably help me to come up with a thesis question. From there I’d be able to make the question more niche and this would help steer me in the direction of research that was more relevant to my final question. Callum suggested that the question needed to be made up of the following domains:

• The design theme: accessibility, in my case.
• The user group: the visually impaired.
• The domain: the product domain that I’m going to investigate, for example e-commerce.
• The platform: the technology that this is being accessed on, for example mobile devices.

He proposed that following this structure would lead me to create a thesis question, statement or hypothesis such as ‘What is being done to improve accessibility for the visually impaired on e-commerce mobile apps?’ which ticks all of Aaron’s boxes for a niche, concise and focused question.

Callum said that because I was missing the last two parts I wasn’t able to come up with a question. Brainstorming ideas and doing more research would fix this as I’d be finding trends in research, for example maybe there’s some really interesting new methods that are being used to improve accessibility to the visually impaired in mobile e-commerce apps that I want to explore more.

We discussed how some of the academic journals I found were from two decades ago and that led us to talk about how accessibility knowledge and people’s attitudes to it are changing as time goes on, so perhaps a brief overview of the history of accessibility or some discussion about key milestones would be a good way to open the report.

We also discussed about sources and not to ‘shun’ articles you might read online just because they’re not in an academic journal. If an article is found online and is up-to-date, well-researched, well-referenced and is written by a credible professional, then why use something that’s 20 years old and written by somebody who has not been in ‘current in the industry’ for years over it just because the style of writing is different?

It was a very productive and helpful call. In return, I gave him some help with some JavaScript and jQuery-related problems he was having in return. Interestingly, the solution was just to basically use CSS! It’s great when you can ask friends for help!

Considering the style of report to write

There are several different styles of report that I can choose. My topic would suit one of the following:

• Extended essay: this is the traditional dissertation-style of report that aims to discuss a topic, answer a question or prove or disprove a hypothesis based around discussion.
• Technical report: similar, but generally includes an experiment, usability testing or creating something to prove a point.
• Industry report: discussion about how a specific industry works and the practices in it.

I can see the extended essay being the easiest format to follow, but the technical report may be more fun to do as it involves actually ‘doing something’ and generating my own data (finding a focus group for testing might be difficult) and the industry report could be interesting to research. If I did the industry report I’d need to really tailor it to ‘what is software vendor X doing to improve accessibility for the visually impaired?’ which could change the direction.

The other option is an ‘editorial style’ which would be like a newspaper report or similar. I might run Storehouse magazine, but this format isn’t for me, though I do enjoy writing articles!

I need to consider these options. Once I have a solid question this will be easier to decide and then I can put this into the report proposal.

Personal goals and timescales

I’d really like to start writing the report proposal before Easter, so either April 17th or 18th, and have it done before April 30th which is when university resumes. Now is the perfect time to write the proposal and do some research: it’s the holidays, I have done all of the work relating to the Broads Authority project and I have no other commitments on at the moment. When I go back to university there will be two weeks of mad-cramming work in for hand-in, so anything that can be done now will save me work later.

References

Anderson, S. (2018). How To Design Websites For Blind/Visually Impaired, Deaf, Disabled & Dyslexic Visitors. [online] Hobo-web.co.uk. Available at: https://www.hobo-web.co.uk/design-website-for-blind/ [Accessed 16 Apr. 2019].

Kaur, A. (2018). Accessibility guidelines for UX Designers. [online] UX Collective. Available at: https://uxdesign.cc/accessibility-guidelines-for-a-ux-designer-c3ba775539be [Accessed 16 Apr. 2019].

Ratcliff, C. (2018). How to design websites for blind and partially sighted people. [online] UserZoom. Available at: https://www.userzoom.com/blog/how-to-design-websites-for-blind-and-partially-sighted-people/ [Accessed 16 Apr. 2019].

Stanley, P. (2018). Designing for accessibility is not that hard. [online] UX Collective. Available at: https://uxdesign.cc/designing-for-accessibility-is-not-that-hard-c04cc4779d94 [Accessed 16 Apr. 2019].

Web Accessibility Initiative (WAI). (2005). Web Content Accessibility Guidelines (WCAG) Overview. [online] Available at: https://www.w3.org/WAI/standards-guidelines/wcag/ [Accessed 16 Apr. 2019].

April 17th 2019 – research, research, research

A very productive day today. I took Callum’s advice and began to brainstorm ideas around visual impairment and research the topic more heavily. I found that by searching online for the following things I was able to come up with a plan for the dissertation which I will be writing about in my report proposal.

• Some statistics about visual impairment in general.
• Statistics about visual impairment and use of technology and specifically websites.
• More detail on what can be done to improve the design and functionality of websites to assist the visually impaired.
• Barriers to technology that the visually impaired face.
• What the visually impaired face when they visit websites from the perspective of a visually impaired person.
• Case studies of websites that have good accessibility features.
• Research on how the visually impaired use computers – including the types of devices they use and the strengths, weaknesses and opportunities of each.
• Case studies of user testing that has involved the visually impaired.

I was looking for emerging patterns and consistent themes whilst researching these, as well as learning much more about the visually impaired and what the current situation is to allow me to understand the topic in far greater depth.

I researched by looking online, reading blogs, reading usability reports, reading research and then drawing spider diagrams of what I was finding on my Surface.

I’ve included embedded PDFs of my notes from the Surface in this post. Below are two ‘general research’ diagrams I made. Later on, the diagrams get more specific.

Statistics about visual impairment in general

The World Health Organisation states that:

• 1.3 billion people have some form of visual impairment (approximately 17% of all people alive – 2017 world population figure of 7.53 billion).
• 188.5 million people in the world live with mild vision impairment.
• 36 million people are blind.
• 2.7 million people have moderate-severe impairment.
• 80% of global visual impairment is deemed ‘avoidable’.
• The majority of visual impairment sufferers are over 50 years old.

In the US, UK and Canada:

• 15-20% of people have reading difficulties.
• 8% of Caucasian males in the US suffer from colour-blindness (0.5% of Caucasian females are also affected).
• 7% of working-age adults have severe dexterity difficulties, some of which caused by partial vision.
• 3-4% of people can’t see well enough to read or write.
• More than 10% of over 70s are affected by visual impairments.
• Around 2 million people in the UK are living with sight loss.

The need to be concerned about visual impairment is increasing because:

• The aging population is set to triple by 2050 – meaning that 1.5 billion of all people alive (approximately 20%) will be in the ‘aging population’
• 56.7 million people in the US alone live with a disability – set to go up.
• 80 million people in the EU alone live with a disability – set to go up.
• 20% of all Australians (approximately 4.92 million people) live with a disability – set to go up.
• The UN Convention of the Rights of the Disabled states that access to information and communication (including the internet) is a basic human right and must be honoured.
• 25% of all disabled adults in the UK have never been online.

W3C WCAG guidelines

In addition to the points listed earlier in this post about good design principles for the visually impaired:

• Users should be guided so that mistakes are not made in the first place.
• Users need to have time to read information, particularly if a screen reader is reading/speaking it to a user slower than a human generally reads (humans generally scan information and don’t read all of the content).
• Non-text elements should have brief descriptions, e.g. video descriptions.
• Captions that can be read by a screen reader should be implemented for non-text elements.
• A text description of data shown on charts and graphs should be available.
• Sign language interpretation of audio should be available for braille screen readers.
• Presentation should be controllable by accessibility modes in the browser.
• Background noise should be low or ‘toggle-able’.
• Users should be able to stop, start and pause audio as well as adjust the volume.
• Text should be scalable up to 200% magnification using a standard web browser without losing text.

Some of these are also part of the general W3C web standards guideline and are not specific to WCAG.

Technology shifts

• Mobile screen usage is higher than desktop screen usage – as of April 17th 2019, StatCounter reports 49% of web traffic is from mobile devices and 47% from desktop devices (tablet devices make 4% of the share).
• Mobile screen usage is believed to have increased by 70% between 2009 and 2014 alone.
• 23% of all web-accessibility related lawsuits since 2000 happened between 2013 and 2016.

Barriers to accessibility for the visually impaired

• Text and images with poor contrast between the foreground and background colour palettes are very difficult to see.
• Not enough text alternatives for non-text elements.
• Not enough auditory equivalents for videos and other graphical elements – even including data on visual graphs.
• Missing visual and non-visual orientation cues.
• Inconsistent page layouts and navigation elements.
• Layouts often lose content (or text does not ‘reflow’ correctly) when the scale is changed (e.g. zoomed in).
• Complicated navigational structures and page structures are difficult to learn.
• Websites, browsers and authoring tools don’t always support the use of custom colour combinations (for the colour-blind).
• Websites, browsers and authoring tools don’t always support keyboard navigation.

In addition to the poor design of websites, there are some other barriers:

• Lack of training or skill.
• Expense of additional hardware and software that is required to use computers.

Accessibility barriers from the perspective of the visually impaired

W3C have some very interesting case studies on their website (referenced below) which give some use-case scenarios and describe how people with disabilities struggle in these scenarios and what would work better for them. The case studies below also helped me to understand the hardware and software the visually impaired use and how it works. These could almost act as user personas.

Colour-blind user on an e-commerce website

• Descriptions are difficult to read due to poor colour contrast.
• Can’t tell the difference between certain colours, so some products look the same (no description with the colour of the item is provided).
• Sites don’t have support for increasing contrast.

85 year old retiree with low vision and hand tremmor

• Uses the internet to blog, read the news and access social media.
• Finds it hard to click on links in forms.
• Finds it hard to read small text.
• Has to increase the scale of websites to be able to read text and thus loses his place when text does not reflow correctly.
• Problems with CAPTCHA verification on social media sites: can’t accurately enter the text because the text is too distorted when enlarged. Better experiences with alternatives.
• He uses a web browser that saves thumbnails of recently visited sites – this helps him keep track of his browsing history and return to commonly accessed websites.
• Uses a special mouse that is easier to control with hand tremmors.

Deaf and blind teenager (focusing mainly on visual impairments)

• She can only see a small portion of the screen and read text when it is significantly enlarged.
• Uses a mobile device with a GPS to orient herself.
• She uses an electronic braille device which includes an electronic calendar, e-mail, browser and note-taking facility.
• She needs to use screen magnification software to enlarge text on websites to a suitable font size.
• She uses screen reader software that outputs text on a refreshable braille device for her to interpret.
• She has to use a large, high resolution and high nit (bright) display.
• Better experience viewing content that is correctly marked-up for the screen reader and reflows correctly when scaled.
• Finds that the text on many websites does not reflow correctly when they are enlarged. Makes content difficult to use.

Blind senior sales member

• Can’t read braille, so screen readers and narrators must be used.
• Uses a screen reader on mobile phone to view the web.
• Screen reader tells her about the structure of the page and the order of content. It can even tell her what’s in tables.
• Information is provided to her in audio format. She finds this easy to understand.
• Screen reader does not work when websites have not been coded with this in mind – e.g. no ‘alt’ HTML attributes used.
• Sites can be completely un-navigable and require time for the screen reader to all the content when no navigation cues have been provided.
• She often finds herself unable to navigate away from a page and must abandon trying to interpret the page altogether.

How Tesco and Google implement accessibility features

Tesco and Google are two examples of websites believed to have good accessibility features, according to W3C.

Tesco

• A ‘pioneer’ in the field, their site launched in 2000 and was redesigned in 2001 to improve accessibility for the partially sighted.
• The column layout was removed for more flexible navigation and page layouts, as well as better scaling and reflowing.
• Descriptions of link text was improved.
• The new site was tested with visually impaired users.
• Pre-Christmas orders in 2001 increased to 700,000 orders with the average spend increasing to £95 per week.
• Over time these changes helped to increase revenue to £13 million per year as more people were able to use the site.

Google

• Contrast is strong between text and page colours to make large amounts of text easier to see.
• AI has been used to learn site usage habits and begin to automate some of them, negating the need for interaction.
• Auto-complete forms help those who struggle to see or type search for things faster.
• Machine learning has been used to create automatically captions for the deaf (YouTube closed captions are a good example), but now it is being used for other things too.

GOV UK usability research and testing with the partially sighted

The GOV UK website is one of my favourite websites because I personally feel that it is one of the best-designed sites there is. Information is clear and easy to read thanks to it not only being no-nonsense and to-the-point, but also presented in a simple manner. I have never not been able to find what I am looking for on that website. As more and more services that used to be completed by post or in post offices are moved online, the government has done extensive research into web accessibility and have a blog dedicated to the design of accessible websites.

• Their research found that the visually impaired use the same kind of devices that sighted people do.
• Screen readers, such as VoiceOver on iOS and MacOS and Narrator on Windows, were commonly-used.
• Different people had the screen readers set to read the screen at different speeds – some incredibly fast (but they understood it) and some much slower. Flexibility was a must.
• They found that patterns on confirmation pages were extremely important – users were able to listen to information from the screen reader and use the tab key on the keyboard to navigate through the confirmation page (or form) and edit any incorrect information.
• Navigating by touch was a very common method of navigation.
• Touch navigation made finding small elements quite difficult.
• Close placement of elements on touch screens made users take longer to enter data as they struggled to find the elements.
• In addition to this, screen readers tended to read the contents of elements that were close to each other quite soon after one another, so positioning them further apart would also help the screen reader clearer to the user.
• Partially-sighted people use ‘muscle memory’ a lot – so consistent page layouts meant that partially-sighted users were able to learn page layouts quickly and navigate through whole websites quickly after learning the initial layout.
• Changes to the page layout massively reduced the confidence of partially sighted testers as they had to re-learn the layout.

Additionally, they also published some interesting information about the use of colours and contrast.

• The use of high contrast colours is essential to aid the colour blind and those with poor vision.
• W3C WCAG standards are followed by designers and feature recommended minimum colour contrasts.
• The GOV UK site uses a 4.9:1 colour contrast between the green call-to-action buttons and the white background of the page. WCAG recommends 4.5:1, so the GOV UK site’s colour contrast is much higher – better for the visually impaired.

Usability survey by the Journal of Blindness Innovation & Research

The JBIR compiled an interesting document detailing the results of a survey that they carried out in 2017, questioning blind users on their thoughts of using technology. Lots of areas were covered.

Device preference

• 35.7% of respondents favoured desktop computers.
• 33.9% favoured laptop computers.
• 17.8% favoured iPhones.
• Braille devices, talking books and other phones made up the remaining 12.6% of the share.
• Devices with a keyboard usually favoured because:
  • ‘Muscle memory’ could be used to learn software, e.g. remembering keyboard shortcuts.
  • Easier to manipulate the screen reader with.
  • Easier to multitask with.

Common problems that blind people face when using the web

• 57% of problems reported were related to CAPTCHA, poorly-labeled buttons, links and images (meaning that screen readers couldn’t be used to describe these elements).
• Flash content and images, particularly products on e-commerce websites, were also mentioned a lot.
• 65% of first-time problems (when using new software or websites) were:
  • Learning to navigate.
  • Configuring new software or hardware.
  • Learning new keyboard commands.
• PDF forms that were incompatible with screen readers were a problem.
• Graphical aspects of websites, including charts, not being navigable by keyboard was also a problem.

Technology changes

Technology changes were met with mixed reception to the respondents.

• 44% of respondents did not like technology change.
  • Most said that the learning curve presented by change of technology, whether it be hardware or software, was difficult.
  • Examples given were the changes between Windows XP and Vista, Windows Vista/7 to Windows 8 and even more minor changes such as Windows 8 to 8.1 because the screen reading software worked differently on 8.1 to 8 and accessibility features were changed.
  • Some users felt that until Windows Vista, Windows operated in the same way, but Vista presented new features that were difficult for blind users to use.
• 32% had mixed experiences.
  • They often described new technology having ‘steep learning curves’, but could understand the benefits of the new technology or could adapt relatively quickly.
  • Some said that they sometimes had trouble at first with new software, such as using iOS for the first time, but soon learned how to use it.
• 14% had positive experiences.
  • Comments such as ‘generally smooth’ and ‘generally intuitive’ were used by respondents describing upgrading their operating system.

Solving problems

• A large number of respondents said that they didn’t like to ask for help.
• Respondents said that they’d ask friends and family for help, but would often give up trying or not ask for help if a problem was too complex or time-consuming to solve.
• However, there were a number of tasks that most respondents felt confident solving alone:
  • Resetting passwords.
  • Converting files.
  • Navigating ‘tricky but usable’ programs and websites.
  • Problems relating to the screen reading software.
• 66% of problems were solved without the assistance of a sighted person.

Consolidating the research

As I was researching, I could see that the need for accessible software was very high and that a lot of websites and apps probably don’t meet all of the W3C WCAG standards. Accessibility of software on mobile devices in particular need attention because keyboards are the preferred input method of the visually impaired and these aren’t generally available on phones, there are fewer screen reader options, scaling text and content is harder on a smaller screen, seeing content at 100% scale is more difficult and mobile usage is increasing.

As I was researching, the UX designer in me was fascinated by what I was reading but noted that patterns were repeating. The developer in me was asking ‘how hard can it be to code for the visually impaired?’

‘How hard can it be? The ultimate UX feat’ – is a technical report for me?

As I kept on researching, in the end there was no escaping the fact that I was keen to try and build something to tackle the key problems discovered by my research today. So, I have decided to write a technical report based around designing a mobile multimedia or mobile e-commerce website for the partially-sighted and then getting my design tested by a group of visually impaired testers.

To me, this seems a good idea because:

• I am really interested in this subject.
• ‘Accessibility’ is a buzz-word, for sure. It’s current, it’s contemporary, it’s on people’s minds.
• I love coding – finding new code, learning new code and talking about code!
• My report can include research about the topic (accessibility for the visually impaired) and the code.
• I can discuss what the obstacles were and how easy or difficult it was to create.

From a UX perspective, this idea has far more scope than my previous one:

• Research on how to design for the visually impaired and what their requirements are.
• Designing a product for them based on that research.
• Testing a prototype with a specific focus group.
• Iterating and coding a solution.
• Evaluation.

It has the potential to follow the UX process exactly.

This can be more than a grade for me in the following ways:

• Learn a new design language.
• Learn new code.
• Improve my usability testing methods.
• Prove myself as an accessibility-conscious UX designer, maybe even research it more and begin to specialise in it.
• Gain a better understanding of social issues such as barriers to technology.
• Design for social good.
• Apply to future practice.

I chose to focus on mobile devices because on the whole it appears to be the least-favoured platform for the visually impaired, yet is becoming the most popular amongst other groups. Therefore, it presents a challenge.

I’m feeling really excited about this and feel that this, and the Year 3 FMP (if my idea can be done) will really put me on the map for Year 3 of university.

Let’s not make this mistake again

A stupendous piece of coding, but being dyslexic I must admit I found it hard to love the design as much.

–Andrew Howard, my A level computer science teacher, on my A level computer science final piece (April 2016).

Those words have rung in my head since April 2016 – some 3 years. I didn’t even need to look back through my coursework to find the quote. This was the quote that made me realise for the first time that accessibility was important.

My A level computer science final piece featured stark white text on a pure black background – it was difficult for my teacher to read.

References

W3.org. (n.d.). Accessibility – W3C. [online] Available at: https://www.w3.org/standards/webdesign/accessibility [Accessed 17 Apr. 2019].

Brotherton, C. (2016). Web Accessibility in the UK – True Facts [infographic] – A Bright Clear Web. [online] A Bright Clear Web. Available at: https://www.abrightclearweb.com/web-accessibility-in-the-uk/ [Accessed 17 Apr. 2019].

StatCounter Global Stats. (n.d.). Desktop vs Mobile vs Tablet Market Share Worldwide | StatCounter Global Stats. [online] Available at: http://gs.statcounter.com/platform-market-share/desktop-mobile-tablet [Accessed 17 Apr. 2019].

Web Accessibility Initiative (WAI). (2017). Diverse Abilities and Barriers. [online] Available at: https://www.w3.org/WAI/people-use-web/abilities-barriers/ [Accessed 17 Apr. 2019].

W3.org. (2018). Google Case Study – WAI-Engage: Web Accessibility Community Group. [online] Available at: https://www.w3.org/community/wai-engage/wiki/Google_Case_Study [Accessed 17 Apr. 2019].

Hassell, J. (2019). The one small thing people in each digital job role could do in 2019 to improve accessibility – Digital Accessibility Experts Podcast 4 – Hassell Inclusion. [online] Hassellinclusion.com. Available at: https://www.hassellinclusion.com/blog/the-one-thing-to-improve-accessibility-in-2019/ [Accessed 17 Apr. 2019].

Horsford, E. (2016). Research with visually impaired users – User research in government. [online] Userresearch.blog.gov.uk. Available at: https://userresearch.blog.gov.uk/2016/01/22/research-with-visually-impaired-users/ [Accessed 17 Apr. 2019].

Horsford, E. (2016). Research with blind users on mobile devices – Accessibility in government. [online] Accessibility.blog.gov.uk. Available at: https://accessibility.blog.gov.uk/2016/06/09/research-with-blind-users-on-mobile-devices/ [Accessed 17 Apr. 2019].

Jarry, A., Chapdelaine, C., Kurniawan, S. and Wittich, W. (2017). Blind Adults’ Perspectives on Technical Problems and Solutions When Using Technology. [online] Nfb.org. Available at: https://nfb.org/images/nfb/publications/jbir/jbir17/jbir070102.html [Accessed 17 Apr. 2019].

Morton, R. (2016). Colour contrast – why does it matter? – Accessibility in government. [online] Accessibility.blog.gov.uk. Available at: https://accessibility.blog.gov.uk/2016/06/17/colour-contrast-why-does-it-matter/ [Accessed 17 Apr. 2019].

Rogers, M. (2017). Website accessibility: disability statistics. [online] Powermapper.com. Available at: https://www.powermapper.com/blog/website-accessibility-disability-statistics/ [Accessed 17 Apr. 2019].

Web Accessibility Initiative (WAI). (2017). Stories of Web Users. [online] Available at: https://www.w3.org/WAI/people-use-web/user-stories/ [Accessed 17 Apr. 2019].

W3C Web Accessibility Initiative (WAI). (2009). Tesco – Case Study of Accessibility Benefits ◦ Web Accessibility Initiative ◦ W3C. [online] Available at: https://www.w3.org/WAI/business-case/archive/tesco-case-study [Accessed 17 Apr. 2019].

Who.int. (2018). Vision impairment and blindness. [online] Available at: https://www.who.int/news-room/fact-sheets/detail/blindness-and-visual-impairment [Accessed 17 Apr. 2019].

Siteimprove. (2016). Why Web Accessibility Should be a Priority Now: 3 Stats to Prove It. [online] Available at: https://siteimprove.com/en-gb/blog/why-web-accessibility-should-be-a-priority-now-3-stats-to-prove-it/ [Accessed 17 Apr. 2019].

April 18th 2019 – putting words on paper

Today I wrote a complete first draft of my report proposal. It’s currently 1,091 words long, so falls within the +/-10% leeway of the 1,000 word maximum, but I will likely find a way to reduce the word count to bring it closer to 1,000. It outlines the problem that I have identified – which is that despite the number of people with visual impairments being well over a billion, at least 70% of websites are still thought to fail to meet basic accessibility standards, and it also outlines what I am going to produce for my technical report and what I hope to get out of it. I also go into some depth about five pieces of academic writing I have identified that could be useful sources as well as the research from the UK government and the Journal of Blind Innovation & Research that I mentioned in yesterday’s entry.

The question

Yesterday’s research and writing the report proposal enabled me to come up with the question, which is: ‘How can the accessibility of mobile e-commerce websites be improved for the visually impaired?’ 

I chose this question because:

• It can’t be answered with ‘yes’, ‘no’, ‘very’ or ‘not really’.
• My research yesterday shows that mobile devices could be harder for the visually impaired to use, but mobile device usage on the whole is increasing.
• My research yesterday shows that non-text elements on a website such as images, videos and charts are what the visually impaired struggle to interpret. My research also suggests that completing forms, inputting information and clicking on links are also difficult tasks. However, resetting passwords on accounts is easy enough. E-commerce websites utilise all of these.
• I can create a prototype of an e-commerce website that demonstrates what could be done to improve accessibility.
• Usability testing will definitely help to answer this question by proving that certain design principles help, or don’t help, the visually impaired.

Academic pieces

From my report proposal draft, these are the academic texts that I have identified and how they will help write this piece.

What Can I say? Addressing User Experience Challenges of a Mobile Voice User Interface for Accessibility’ (2016) by Eric Corbett and Astrid Weber from Google Research discusses the challenges faced when creating applications for those with visual impairments or dexterity disabilities that rely on voice interaction. ‘Patterns for How Users Overcome Obstacles in Voice User Interfaces’ (2018) is written by five researchers at Drexel University, Philadelphia and uncovers the challenges and annoyances that people face when using voice UIs. This and the piece written by Google Research will help me to understand if a voice UI is a good solution for the visually impaired and how people interact with them. 

‘Exploring Interface Design for Independent Navigation by People with Visual Impairments’ (2015) is written by professors at Carnegie Mellon University, Pittsburgh, USA and researchers from IBM in Tokyo. The piece explores how nine people with visual impairments responded to different instruction intervals, precision, output modalities, and landmark use during in situ navigation tasks. The piece was written to provide direction and open questions for future work on adaptive navigation interfaces.  

‘Interface design for older adults’ (2001) by Mary Zajicek from Oxford Brookes University is an older report, but still potentially relevant to this report. It explores what can be done to make the web a more accessible place to people over the age of 70. It explores it specifically from the perspective of the visually impaired. This is interesting to me because formative research indicates that over 70s are some of the page most likely to be affected by visual impairment. Over 70s potentially form a large part of my target audience. 

‘Interviewing Blind Photographers: Design Insights for a Smartphone Application’ (2013) identifies that is generally understood how blind people take photographs, but the process of how they store, organise and share digital photographs with sighted help is not understood. The authors (four professors from the University of California, Santa Cruz) conducted interviews with eleven blind individuals to learn how they do it with the intention of using this research to develop a smartphone app for the blind that would enable them to take ‘good’ photos and store, edit and share them. Their findings could provide invaluable insight as to how blind users complete complex tasks without sighted help.  

There are also several other texts that could be useful that I have identified, but I have not included these in my report proposal due to the word count.

Limitations of my proposal

Creating my own accessibility website prototype and testing it with the visually impaired is easier said than done. There’s going to be a lot to research and learn, as well as a lot of contacting of local charities and organisations to find test volunteers.

The following is what I put in my report proposal draft today about the potential limitations:

Time: it could take a long time to research the code and guidelines to use for the prototypes. Finding a user group to test could also take time and may require asking several organisations for test volunteers.  

There may additional specialist hardware and software that is required to make this work correctly that may be difficult to obtain.  

Data collection and testing method: qualitative observations alone may not be enough to meaningfully answer the question. 

Detailing the project in under 5,000 words could be a challenge for me. The structure needs to be split into outlining the problem, designing the prototype and the usability testing of the prototype, which ultimately answers the question.  

This will however be a very interesting and exciting project to produce and a learning experience in terms of researching design languages for the visually impaired and how to code accessibility features into websites.  

Thoughts on writing the report proposal draft

I found it was a helpful exercise because it enabled me to finalise my question and consider exactly how I’m going to approach this task.

I didn’t really know where to begin with writing the proposal, so I started by writing the bit that I was most confident about which interestingly was the section about the limitations. I knew that this proposal had some obvious limitations. From there I started to write about how I was going to answer my question by conducting usability testing, but without a question I turned to yesterday’s research and was able to come up with one easily. Coming up with a question also meant that it was easy to list the aims and objectives. My attention then turned to the introduction where I defined what ‘visual impairment’ and ‘accessibility’ were (the keywords in the question) and also provided some statistics showing that it’s an issue in design that perhaps isn’t being addressed.

Writing the literature review was probably the hardest bit, but looking through the sources I found on Tuesday, I was able to read the abstract of each to write a short description of what each was about and explain why it would be useful/relevant to my own research. After that, all I had to write was a short sentence explaining that this will be an exciting and interesting project.

The proposal will no doubt change a lot between now and May 10th, but I feel really pleased that I was able to stick to my personal timeline and get the report proposal draft written before Easter and I also feel really good about having the first draft of the proposal written (and all of the Broads Authority project written up!) some three weeks before the hand-in. Hopefully this makes the weeks at university after the Easter holiday a little less stressful.

What’s next?

I will continue to research the dissertation topic. I have a call with the Accessibility Ambassador at Microsoft on April 26th which I am looking forward to!

I’ll try and remove around 90 words from the proposal to bring it down to 1,000 words.

I need to also research how to code websites that work with screen readers and follow the W3C WCAG 2.1 guidelines, as well as research the general principles that go into designing an e-commerce website.

References

Adams, D., Gallagher, T., Ambard, A. and Kurniawan, S. (2013). Interviewing blind photographers. Proceedings of the 15th International ACM SIGACCESS Conference on Computers and Accessibility – ASSETS ’13.

Brady, E., Sato, D., Ruan, C., Takagi, H. and Asakawa, C. (2015). Exploring Interface Design for Independent Navigation by People with Visual Impairments. Proceedings of the 17th International ACM SIGACCESS Conference on Computers & Accessibility – ASSETS ’15.

Corbett, E. and Weber, A. (2016). What can I say?. Proceedings of the 18th International Conference on Human-Computer Interaction with Mobile Devices and Services – MobileHCI ’16.

Legislation.gov.uk. (2010). Equality Act 2010. [online] Available at: http://www.legislation.gov.uk/ukpga/2010/15/contents [Accessed 18 Apr. 2019].

La Rocca, D. (2016). Seventy Percent of Websites Are Breaking the Law on Accessibility – Here’s How and Why That Needs to Change. [online] Huffingtonpost.co.uk. Available at: https://www.huffingtonpost.co.uk/damiano-la-rocca/website-accessibility_b_9931304.html [Accessed 18 Apr. 2019].

Myers, C., Furqan, A., Nebolsky, J., Caro, K. and Zhu, J. (2018). Patterns for How Users Overcome Obstacles in Voice User Interfaces. Proceedings of the 2018 CHI Conference on Human Factors in Computing Systems – CHI ’18.

Ridbc.org.au. (n.d.). Vision. [online] Available at: https://www.ridbc.org.au/blindness [Accessed 18 Apr. 2019].

MDN Web Docs. (2019). What is accessibility?. [online] Available at: https://developer.mozilla.org/en-US/docs/Learn/Accessibility/What_is_accessibility [Accessed 18 Apr. 2019].

Zajicek, M. (2001). Interface design for older adults. Proceedings of the 2001 EC/NSF workshop on Universal accessibility of ubiquitous computing providing for the elderly – WUAUC’01.

April 19th 2019 – how the visually impaired use a computer

Today was about understanding what it might be like to use the computer as somebody who is visually impaired. I also did some research to better my understanding of how screen readers work (so that I could prototype a design that would work properly with one) and what kind of code I’d need to use to code a website designed for the visually impaired.

How a screen reader reads content

Understanding how a screen reader reads content is important because it can totally change the way that content is written on the website.

Screen readers pause for:

• Full stops
• Semi-colons
• Commas
• Question marks
• Exclamation marks
• Ends of paragraphs

Some screen readers can emphasise or ‘read’ punctuation depending on verbosity settings.

Acronyms

Most screen readers will attempt to pronounce acronyms. Acronyms that are commonly pronounced as words by people, such as ‘NASA’ (which most people pronounce as ‘nasser’ rather than ‘N.A.S.A.’) will be read as the words most people say. ‘SQL’ is often read as ‘sequel’ even though some people would say ‘S.Q.L.’.

Homographs and screen readers

Words that can be pronounced in two or more ways, but have the same spelling, can throw screen readers off. ‘Read’ can be pronounced as ‘read’ or ‘red’. Most screen readers can evaluate the context and choose the correct pronunciation, but sentences such as ‘I read the news everyday’ can be ambiguous if the tense cannot be determined. ‘Content’ is another example of a homograph that can be confusing.

General reading

• Screen readers can be paused and words and whole passages can be repeated.
• Screen readers can read words letter-by-letter and emphasise capitals and ellipses.
• Letters can be read aloud as they typed, but sensitive information such as passwords are usually read as ‘star’ or ‘asterisk’ as the information is typed into the field.
• On webpages, the content in the <title> HTML tag is the first thing to be read.
• Alternative text (the HTML <alt> tag) is read by screen readers. The JAWS screen reader precedes the alt text with the word ‘graphic’, since alt text is often applied to images. ‘Graphic link’ is used if the image is a hyperlink.
• Most screen readers do nothing if there is no data in the alt tag. Some screen readers can be set to read the file name as a compromise.
• Screen readers often tell the user how many rows and columns are in a data table.
• If tables are marked up correctly, the screen reader can read the column and row headings to the user as they move into the cell. Users can navigate around tables.

The linear nature of screen readers and the need for clear heading structure

Sighted users have the ability to scan pages and don’t need to fully read content. They can also look at graphical elements. Those using screen readers can’t do this, so content is read from top to bottom and reads a little like automated phone menus where not all of the content is available at once. This means that users need to progress through interfaces in a step-by-step manner, starting from the top of the page and working their way to the bottom.

The linear nature of screen readers means that it’s crucial to use correct heading structure and use the heading tags correctly.

You should not use CSS text decoration such as setting the font weight to bold and font style italic to content in p tags to create headings, since screen readers cannot identify these as actual headings or emphasise text in them. Instead, you must use the appropriate h1, h2, h3, h4, h5, and h6 tags and use them correctly.

h1 tags should only be used for top-level headings. The rest are all sub-headings, becoming less important as the number increases.

Semantic vs visual HTML markup

This is really important for screen readers. Screen readers can accentuate their ‘reading voices’ to take into account content that needs to be more ‘stressed’ in spoken word.

For example, if you want the word ‘important’ to be ‘stressed’ in the sentence: ‘It’s important to check the oil!’, you might use the following HTML:

<p>It's <span style="font-weight: bold">important</span>  to check the oil!'</p>

This markup is particularly common with content management systems, like WordPress.

A screen reader will read this in the same monotone voice that it reads the rest of the content in the p tag. To get it to accentuate the tone for the content in bold, use the <strong> tag instead.

<p>It's <strong>important</strong> to check the oil!</p>

It’s a similar story for italics too. Screen readers can accentuate the tone for content in italics too. Traditionally, web developers use the following mark-up for italics:

<p>It's <i>important</i> to check the oil!</p>

Or they might use a span and set the font-style in the span to italic, again common with WordPress.

To get a screen reader to accentuate the italic content, use the em tag instead:

<p>It's <em>important</em> to check the oil!</p>

Setting the font-weight to bold and using the i tag or setting the font-style to italic are all visual markup methods. Using the strong and em tags are semantic markup methods.

Lists

Lists must be used correctly when coding websites for screen readers. Unordered lists must be used when there is no particular order to the list. Ordered lists must be used if the content presented in the list follows a hierarchy. Definition lists have to have definition descriptions.

Lists must be only be used for lists, not to indent text.

Code to make text ‘reflow’ correctly (CSS)

Text ‘reflowing’ is text is that is responsive. On most websites, when you increase the page scale, often text goes out of view and the user has to scroll to read the text – this is a major usability flaw for a lot of visually impaired people who need to increase the scale of websites to see them properly. The reason this happens is because most developers define font sizes with absolute measurements, such as pixels. See the animation below.

Here’s the code:

h1 {
    font-size: 60px;
}

p {
    font-size: 16px;
}

The solution is to just use viewport widths and heights (vw or vh) instead, as these are a percentage of the page height and width and so the size of the text doesn’t change with the page scale, so the text never ‘disappears off the screen’. See the animation below.

Here’s the code:

h1 {
    font-size: 8vw;
}

p {
    font-size: 3vw;
}

Code to add screen reader-compatible captions to images and other graphics (HTML)

You can simply add the ‘alt’ attribute to HTML elements. For example, the below will render a screen reader to read ‘red roses in a garden’.

<img src="red-roses.jpg" alt="red roses in a garden"/>

Similarly, when the user places their cursor over the image, in some browsers the alt text will appear in a small dialog above the image.

Code to read different languages (HTML)

The HTML attribute ‘lang’ can be used to determine languages. Most screen readers read in the language of the system locale, but will attempt to read foreign languages in the system locale language. For example, if the system is set to English, but the sentence ‘I am called Jason in German is ‘Ich heisse Jason’.’ is read, the screen reader will attempt to read this sentence in English.

The ‘lang’ attribute can be used to rectify this.

<p>I am called Jason in German is <span lang="de">'Ich heisse Jason'</span>.</p>

Furthermore, all HTML elements with the ‘lang’ attribute can be targeted in CSS, for example any text in an HTML element with the ‘lang’ attribute can be made italic like so:

span[lang] {
    font-style: italic;
}

The result will be: I am called Jason in German is ‘Ich heisse Jason’.

Code to get screen readers to recognise HTML landmarks (e.g. headers and navigation elements)

Most of the time it’s as simple as using the appropriate <header> and <navigation> HTML tags and placing content within those.

These are known as ‘ARIA landmarks’ (Accessibility of Rich Internet Applications) and are W3C protocols. Other ones include:

<banner> for site-orientated content such as the name of the site and the logo.

<navigation> for navigation links for the document or site.

<main> holds the main content of the document.

<search> for search elements.

<article> for standalone content that makes sense when removed from the context of the rest of the document, for example blog posts, article pages and comments.

<complementary> for content that supports the main content.

<contentinfo> child content such as footnotes, copyright information and privacy statements.

ARIA roles, properties and states

ARIA roles define what an element does. ARIA roles can override the HTML roles, for example a form could be given the role of search by using the following markup:

<form role="search">

In default HTML, the form has a role of ‘form’ which cannot be overriden.

ARIA properties define properties of elements, for example you can specify an element must be interacted with by using ‘aria-required=’ and then using the boolean ‘true’ or ‘false’ to determine if it needs to be interacted with.

<input aria-required="true">

Would mean that this input is required before something like a form can be submitted.

ARIA states are similar to the properties and use a similar syntax. ‘aria-disabled=’ is a good example.

Improving keyboard accessibility

Visually impaired users generally navigate using the tab key. ARIA can also assist with improving keyboard accessibility where the default tab order is not ideal and CSS can’t change the order of the tab order (by rearranging the position and order of elements) through the use of the tabindex attribute.

Take the list below:

<ol>
    <ahref="/home">Home</a>
    <ahref="/about"tabindex="2">About</a>
    <ahref="/portfolio"tabindex="3">Portfolio</a>
    <ahref="/contact">Contact</a>
</ol>

In an ideal world, you wouldn’t use this because of the potential confusion that this can create. You can see that the ‘File’ button and the URL bar in Chrome actually gain focus before any items in the organised list, so manipulating the tab order could be a confusing experience. Ideally you’d restructure your HTML or adjust the position of elements in CSS to rectify tab order problems first before trying this.

Using the computer as somebody who is visually impaired

Understanding what it’s like for the visually impaired to use a computer and browse the web is crucial in order to help me answer my thesis question. To get an understanding, I installed a screen reader and a piece of software that mimics colour blindness and recorded my experiences.

I remembered that Windows 10 installation now includes the option to install by using your microphone to ‘talk’ to the setup wizard or use the Microsoft Narrator. I recorded a demonstration of this, below.

There are several different screen readers available – operating systems even come with them built-in: MacOS and iOS ship with VoiceOver and Windows ships with Narrator. However, NVDA is a free screen reader that is popular, so this is the one I will likely be using to experiment with using the computer with a screen reader. However, with it not being compatible with mobile devices, I’ll likely use VoiceOver on an iPhone when the time comes for testing my prototype. It’s also important to note that different screen readers work well with different browsers. NVDA apparently works well with Firefox, whereas Microsoft Narrator is more suited for Microsoft Edge. JAWS works best with Chrome and Safari.

Installing NVDA was an interesting experience. Setting up screen readers was a task that blind people felt confident with according to the survey by JBIR and installing NVDA shows how even the set-up wizard has been made to be easy for the visually impaired to use. The use of sounds and ‘speaking’ is crucial. Watch my video below demonstrating this.

What’s next?

The next stage of my research is mainly primary research. I’ll be trying to use modern websites with the screen readers and learning more about the code discussed in today’s entry to better my understanding of coding web pages for the visually impaired.

Reflections on learning about the markup code today

Wow! Now it’s easy to see why a shocking 97.8% of the top 1 million home pages on the internet fail to meet W3C WCAG guidelines – so much extra thought, care and attention needs to go into the design and code of websites to enable them to meet the standards. If every developer put the time in to meet these standards, not only would the web be a more accessible place, but every site’s HTML markup would be exceptional with proper consideration given to laying content out in the appropriate structure, order and with the correct tags. ‘Messy HTML’ would be a thing of the past. Copywriters would have a much clearer understanding of how the use of punctuation and text decoration affects the tone of the content of a website. Their understanding of how their words are spoken, as opposed to just read, will be much greater. Those who write for the web or books will suddenly be thinking far more like playwrights and screenwriters.

This will honestly change the way I write HTML and website copy.

I could honestly sit and research all of this hours, which is a good job because that’s going to be doing until about November! It seems clear to me that I’ve chosen the right topic for my dissertation. Already I’m loving researching the new code (and putting some of it into practice) as well as researching all about how the visually impaired use computers.

References

Welcome to the Official DreamHost Blog. (2018). 10 Ways to Make Your Website Accessible – DreamHost. [online] Available at: https://www.dreamhost.com/blog/make-your-website-accessible/ [Accessed 19 Apr. 2019].

Cottrell, Stella (2014) Dissertations and Project Reports: A Step by Step Guide. Palgrave Macmillan

Duncan, L. (2013). Designing A User Friendly Website For The Blind – Search Engine Journal. [online] Search Engine Journal. Available at: https://www.searchenginejournal.com/designing-a-user-friendly-website-for-the-blind/66457/ [Accessed 19 Apr. 2019].

Make WordPress Accessible. (n.d.). Font sizes and resize text. [online] Available at: https://make.wordpress.org/accessibility/handbook/design/font-sizes-and-resize-text/ [Accessed 19 Apr. 2019].

Blog.usablenet.com. (2018). How and Why to Design Your Site for Screen Reader Compatibility [BLOG]. [online] Available at: https://blog.usablenet.com/how-why-design-your-site-for-screen-reader-compatibility [Accessed 19 Apr. 2019].

W3schools.com. (n.d.). How To Create a Responsive Text. [online] Available at: https://www.w3schools.com/howto/howto_css_responsive_text.asp [Accessed 19 Apr. 2019].

Webaim.org. (2013). WebAIM: Accessibility of Rich Internet Applications. [online] Available at: https://webaim.org/techniques/aria/ [Accessed 19 Apr. 2019].

Webaim.org. (2017). WebAIM: Designing for Screen Reader Compatibility. [online] Available at: https://webaim.org/techniques/screenreader/ [Accessed 19 Apr. 2019].

Webaim.org. (2016). WebAIM: Keyboard Accessibility – Tabindex. [online] Available at: https://webaim.org/techniques/keyboard/tabindex [Accessed 19 Apr. 2019].

Webaim.org. (2013). WebAIM: Semantic Structure. [online] Available at: https://webaim.org/techniques/semanticstructure/ [Accessed 19 Apr. 2019].