Personalising User Interfaces: Meeting the access needs of the individual

An investigation into personalisation as a tool for improving accessibility

Joe Lamyman BSc
Submitted for the MSc by Research qualification

University of York
Department of Theatre, Film, Television and Interactive Media
December 2020

Abstract #

As recent legislation requires that public sector websites meet the Web Content Accessibility Guidelines (WCAG), this thesis explores how accessibility can be improved for the individual user rather than the needs that come with specific disabilities. In order to improve digital accessibility for the individual, personalisation is employed to allow users to change the user interface of e-commerce websites, to better meet their needs.

This research analyses literature relating to the difficulties in conforming to the WCAG, development methods used for improving accessibility and previous work around the subject within the same area that looks at adaptable user interface solutions. Following this, developer interviews are used to provide an understanding as to how developers define accessibility, as well as the challenges that are being faced when trying to implement accessible websites. This work illustrates that between those interviewed, there was no single definition of accessibility and that the needs of businesses are prioritised ahead of the needs and goals of individuals.

With an understanding of the problems facing individuals and those seeking to create accessible websites, 2 studies were conducted. The first, Bog Roll Business Builder, used an interactive study to understand the features of a user interface that could be personalised to better meet the needs of an individual. The second study, Miss Thread, puts these features into a typical fashion e-commerce website, allowing for the testing of affordances and development methods with both disabled users and developers respectively.

The implications of this work provide a foundation for future investigation into personalisation. The results of the studies conducted show a promising insight into personalisation and how it could feasibly be implemented to improve accessibility for the individual.

Table of contents #

• Abstract
• Table of contents
• List of tables
• List of figures
• Acknowledgements
• Author’s declaration
• 1. Introduction
  • 1.1 Background context
  • 1.2 Key terms
  • 1.3 The problem space
  • 1.4 Research questions
  • 1.5 Research objectives
  • 1.6 Scope of the research
  • 1.7 Project outline
• 2. Literature review
  • 2.1 Understanding the difficulties with current accessibility guidelines and reasons for poor compliance
    • 2.1.1 The Web Content Accessibility Guidelines and legislation
    • 2.1.2 Accessibility in the context of e-commerce
    • 2.1.3 Understanding the lack of accessible websites
    • 2.1.4 Summarising the difficulty with accessibility guidelines and reasons for poor compliance
  • 2.2 Development methods for improving accessibility through the user interface
    • 2.2.1 Contexts of use and resulting development trends
    • 2.2.2 Consistently failing users
    • 2.2.3 Summarising development methods for improving accessibility
  • 2.3 Adaptable user interface solutions, investigating similar work done in the same area
    • 2.3.1 An overview of adaptable interfaces
    • 2.3.2 Summarising the research into adaptable user interface solutions
  • 2.4 Conclusion
• 3. Interviews with web designers and developers: Understanding attitudes towards accessibility
  • 3.1 Introduction
  • 3.2 Goals
  • 3.3 Participant roles and coding
  • 3.4 Working towards a theory
  • 3.5 Conclusion
    • 3.5.1 Goal: To learn how developers define accessibility
    • 3.5.2 Goal: To understand challenges faced by developers when trying to implement accessible software
    • 3.5.3 Goal: Identify potential opportunities or challenges for accessibility in the future
• 4. Study 1: The Bog Roll Business Builder
  • 4.1 Introduction
  • 4.2 Similar projects and inspiration
  • 4.3 Designing the Bog Roll Business Builder website
    • 4.3.1 Initial considerations
    • 4.3.2 Enabling live customisation
    • 4.3.3 Storing information
  • 4.4 Accessibility considerations
    • 4.4.1 During the design
    • 4.4.2 Accessibility testing
  • 4.5 Method
    • 4.5.1 Participants
    • 4.5.2 Materials
    • 4.5.3 Design
    • 4.5.4 Procedure
  • 4.6 Results
    • 4.6.1 Text size
    • 4.6.2 Additional product information
    • 4.6.3 Product options
    • 4.6.4 Image position
    • 4.6.5 ‘Buy’ button position
    • 4.6.6 Colour scheme
    • 4.6.7 Display of reviews
    • 4.6.8 Spacing size
    • 4.6.9 Additional information
  • 4.7 Comparative Analysis
  • 4.8 Feedback
    • 4.8.1 Key feedback
  • 4.9 Conclusion
    • 4.9.1 Areas for improvement
    • 4.9.2 Future areas of research
    • 4.9.3 Summary
• 5. Study 2: Miss Thread
  • 5.1 Introduction
  • 5.2 Inspiration
  • 5.3 Designing the prototype website
  • 5.4 Structuring the prototype
  • 5.5 Disabled participants feedback on the prototype
    • 5.5.1 Testing the prototype with disabled participants
    • 5.5.2 Working towards a theory: Accessible, personalised designs
  • 5.6 Developer feedback on the prototype
    • 5.6.1 Understanding the developers’ needs
    • 5.6.2 Working towards a theory: A revised development method with personalisation
  • 5.7 Conclusion
    • 5.7.1 Limitations of the study
    • 5.7.2 Future areas of research
    • 5.7.3 Summary
• 6. Conclusions
  • 6.1 Reviewing research objectives
    • 6.1.1 Research question 1
    • 6.1.2 Research question 2
  • 6.2 Limitations
  • 6.3 Implications of this work
• 7. Appendix
• 8. References

List of tables #

1. Table 1: post hoc pairwise comparisons for text size, whole sample (N = 174)
2. Table 2: post hoc pairwise comparisons for additional product information, whole sample (N = 171)
3. Table 3: post hoc pairwise comparisons for product options, whole sample (N = 169)
4. Table 4: post hoc pairwise comparisons for the image positions, whole sample (N = 171)
5. Table 5: post hoc pairwise comparisons for the 'Buy' button position, whole sample (N = 171)
6. Table 6: post hoc pairwise comparisons for the ‘Buy’ button position, disabled participants (N = 14)
7. Table 7: post hoc pairwise comparisons for the colour scheme, whole sample (N = 166)
8. Table 8: post hoc pairwise comparisons for the display of reviews, whole sample (N = 170)
9. Table 9: post hoc pairwise comparisons for spacing size, whole sample (N = 173)
10. Table 10: post hoc pairwise comparisons for additional information, whole sample (N = 162)
11. Table 11: post hoc pairwise comparisons for additional information, whole sample (N = 14)
12. Table 12: comparison of analysis between whole sample and disabled participants subset

List of figures #

1. Figure 1 - Screen Resolution Stats Worldwide Nov 2009 - Nov 2020 (statcounter, 2020)
2. Figure 2 - Desktop vs Mobile vs Tablet Market Share Worldwide Nov 2009 - Nov 2020 (statcounter, 2020)
3. Figure 3 - Example of Atomic Design applied to the Instagram application (Frost, 2016)
4. Figure 4 - Histogram describing the frequency of the age groups selected by all participants, whole sample (N = 99), the mode was 18-29 years old (n = 44)
5. Histogram 1: Histogram describing the frequency of text options selected by all participants, whole sample (N = 174)
6. Histogram 2: Histogram describing the frequency of text options selected by participants that identified as having a disability, sample group (N = 14)
7. Histogram 3: Histogram describing the frequency of additional product information options selected by all participants, whole sample (N = 171)
8. Histogram 4: Histogram describing the frequency of additional product information options selected by participants that identified as having a disability, sample group (N = 14)
9. Histogram 5: Histogram describing the frequency of product options selected by all participants, whole sample (N = 169)
10. Histogram 6: Histogram describing the frequency of product options selected by participants that identified as having a disability, sample group (N = 14)
11. Histogram 7: Histogram describing the frequency of image position options selected by all participants, whole sample (N = 171)
12. Histogram 8: Histogram describing the frequency of image position options selected by participants that identified as having a disability, sample group (N = 14)
13. Histogram 9: Histogram describing the frequency of ‘Buy’ button position options selected by all participants, whole sample (N = 171)
14. Histogram 10: Histogram describing the frequency of ‘Buy’ button position options selected by participants that identified as having a disability, sample group (N = 14)
15. Histogram 11: Histogram describing the frequency of colour scheme position options selected by all participants, whole sample (N = 166)
16. Histogram 12: Histogram describing the frequency of colour scheme options selected by participants that identified as having a disability, sample group (N = 14)
17. Histogram 13: Histogram describing the frequency of the display of reviews options selected by all participants, whole sample (N = 170)
18. Histogram 14: Histogram describing the frequency of the display of reviews options selected by participants that identified as having a disability, sample group (N = 14)
19. Histogram 15: Histogram describing the frequency of the spacing size options selected by all participants, whole sample (N = 173)
20. Histogram 16: Histogram describing the frequency of the spacing size options selected by participants that identified as having a disability, sample group (N = 14)
21. Histogram 17: Histogram describing the frequency of the additional information options selected by all participants, whole sample (N = 162)
22. Histogram 18: Histogram describing the frequency of the additional information options selected by participants that identified as having a disability, sample group (N = 14)

Acknowledgements #

Throughout my whole degree, I have been lucky enough to be supported by the fantastic Interactive Media team. In particular, my supervisors for this thesis, Dr Anna Bramwell-Dicks and Dr Debbie Maxwell, have supported and guided me through a challenging year, for which I am extremely grateful and appreciative. They have fielded my many panicked emails, answered all of my questions and helped me to develop this work, skilfully enabling me to reach the point where I am writing this section as the last part of my thesis.

I'd like to thank Dr Jenna Ng for inspiring and encouraging me to undertake this challenge, not to mention all of the guidance and advice that has helped me throughout the past year.

I would like to acknowledge all those involved with the Interactive Media degree. To the staff and GTAs who work tirelessly to support all students, thank you. All of the Interactive Media students that I've been lucky enough to meet this past year, your diverse work and multitude of skills are truly inspiring and I would like to thank you for allowing me to further develop myself by teaching your website design and development module.

I have thoroughly enjoyed this work and would like to thank everyone who took part in any part of this research. If you offered your time to be interviewed, used my prototypes or even developed your own toilet roll selling shop, thank you.

In what has been a difficult year for all (if you are reading this much later than the year 2020, it's not one worth remembering), thank you to my friends that have been there for me. Your ongoing support and the kindness shown towards me is cherished, thank you Chris, Jack, Jade, James, Matt and Siobhan.

Thanks to my parents for your never-ending support. Thank you for always listening and being patient with me.

Finally, thank you Naomi for always being there for me and supporting me constantly over the past year. Your encouragement, reassurance, care, and patience has steadied me and allowed me to complete this work.

Author's declaration #

I declare that this thesis is a presentation of original work and I am the sole author. This work has not previously been presented for an award at this, or any other, University. All sources are acknowledged as References.

The only piece of work that has been presented elsewhere is a 1,000 word summary of the introduction and literature review, written as a blog post for the York Disability Rights Forum’s website. This was done to increase the recruitment of participants for the studies included in this thesis. The blog post can be found on the York Disability Rights Forum’s website, titled ‘Digital Accessibility for the Individual’.

1 - Introduction #

This introduction provides an overview of the background context of the subject area, key terms used throughout this thesis, the problem space; and as a result, the research questions, before detailing the research objectives, scope and outline of the project.

1.1 Background context #

The World Wide Web has allowed for communication and interaction of different users and cultures like never before. The use of the Internet puts the world’s wealth of information at a user’s fingertips; a quick search for ‘Online shopping’ returns 25,270,000,000 results. It is easy to imagine the benefits of the Internet: everyone can use their own device, wherever they are, all with access to the same content. There are no longer physical barriers in place preventing people with accessibility needs from achieving their goals. The World Wide Web Foundation, led by Tim Berners-Lee, a key architect of the Internet’s form, designed a Contract for the Web (2020) to safeguard the use of the Internet. Within this contract, a key principle is to ‘Make the Internet affordable and accessible to everyone’. In order to help make the web more accessible, the Web Content Accessibility Guidelines (WCAG) have been developed. The aims of the guidelines are to make websites perceivable, operable, robust and understandable by anyone, no matter their accessibility needs.

In 2019, an automated test of 1,000,000 of the world's most visited websites was conducted to check for WCAG conformance. The testing found that 97.8% of the homepages were not accessible, as they did not meet the WCAG (WebAIM, 2019). That means that at least 978,000 of the world's 1,000,000 most visited websites contain at least one page that is inaccessible to users who are accessing the web with the use of assistive technology. New legislation attempts to tackle this issue. The European Union introduced a directive in 2016, enforcing that all public sector websites (from September 2020) will have to conform to WCAG Level 2.1 AA (European Union, 2016). This is the first time that legislation has required compliance to a testable, quantifiable accessibility standard.

However, a website that achieves WCAG 2.1 AA conformance may not be usable by all users. The Web Content Accessibility Guidelines have been created to make content accessible for people with different disabilities (Lopes et al., 2010). The guidelines do not take into account an individual's context of use, their needs or their goals when accessing content. The guidelines highlight this gap in their coverage with the following statement, taken from the WCAG Introduction (W3C, 2020):

Although these guidelines cover a wide range of issues, they are not able to address the needs of people with all types, degrees, and combinations of disability.

1.2 Key terms #

Given the way that terms in the space are somewhat new and continually evolve alongside the release of new specifications and standards, this subsection will seek to explain these terms and the context in which they will be used within this thesis.

Given the subject matter of this thesis, the term 'web[site] accessibility' is a key concept, referred to frequently. Accessibility is ensuring that websites can be used by as many people as possible and that nobody is excluded. This definition of web accessibility also recognises that accessibility is not static; accessibility needs can change depending on location, health or the equipment being used (Government Digital Service, 2019).

In this thesis, the term personalisation is employed in relation to the action of an individual customising an object (either physically or digitally) in order to align with the individual's needs and goals. In this field, the terms 'customisation' and 'personalisation' are used somewhat interchangeably to denote this activity. However, a user could customise an object for a number of reasons, such as for mass appeal or as an act of protest. Therefore, the term personalisation has been chosen specifically for use in this thesis for its semantics in relating directly to the user's needs and goals.

1.3 The problem space #

The Click-Away Pound Report 2019 (Williams and Brownlow, 2020), is a report that focuses on the loss of business caused by e-commerce websites' lack of accessibility. The study identifies the value of business lost due to inaccessible processes and also highlights the most frequently encountered issues that prevent users from accessing websites. The report estimates that in 2019 alone, the combined value of users that clicked-away when encountering an inaccessible website was £17.1 billion. It is estimated that the UK's population spent around £106.46 billion on e-commerce sites in 2019, meaning that 16% of spending has been lost due to inaccessible websites. 86% of participants answered that they would spend more online if sites were more accessible, allowing them to complete their purchases.

However, these statistics alone fail to depict the discrimination faced by those with disabilities. As an individual with a disability, you may not be able to purchase an item or access a service online, because the website has not been designed with your accessibility needs in mind. Instead, you must now find an alternative method to purchase the item or access the service. However, this may be a service that you are required to access, for example paying your council tax online through your local council's website. The onus is now on you, an individual, to find an alternative way to complete this process. As a result of the failings of designers and developers, your experience online is worse than those who do not share your accessibility needs.

To enforce accessibility compliance, legislation has been enacted to require websites to adhere to standards, such as the WCAG. The EU Accessibility Directive (European Union, 2016), which is enforced in the UK as of 2018, enforces that Public Sector websites meet WCAG 2.1 AA specification. Guidance around this legislation explains that public sector websites will be monitored and tested for compliance with the guidelines (Government Digital Service, 2018). However, as mentioned earlier in this section, the WCAG cannot accommodate for all needs, particularly when there are individuals with combinations of disabilities whose needs do not match those of whom the WCAG were designed for (W3C, 2018). Therefore, even though the WCAG provides a way for a lot of individuals to access content on the web, there is still room to make further improvements to help as many people as possible have access.

As individuals, all seeking to use the web within different contexts, with our own independent needs and goals, it is inconceivable that there is a single design for a website that will accommodate the needs of all users. This has been apparent from the early days of the web, with a paper from 2003 by researchers at the University of Washington, Google and IBM (Weld et al., 2003), who investigated automatically personalising user interfaces, to directly tackle this issue of 'one-size-fits-all' designs. The researchers identified that each user deserves an individual interface, designed for their device and objectives, but explained that this is not possible due to the lack of designers to manage extensive studies. In regards to customisation of interfaces, the researchers explain that it is not possible as users are not able to 'customise effectively', due to a lack of understanding of scripting and other manual overrides that were afforded at the time.

The majority of research around personalisation in the field tends to relate to automation and machine learning, attempting to discover ways to send the most relevant content to a user without them having to do anything. This automation and learning is based on historical data of the user's interactions and vague peripheral information that can be scraped from the browser. This overcomplicated approach, giving users what we think they need based on partial data, is a concept labelled as colonial design. Colonial design is explained by Laura Kalbag (2017) as an issue caused by a lack of diversity in teams, where developers and designers will create solutions that they believe will solve everyone's problems, failing to take into account the differences in individuals' needs and goals. In-turn, colonial design leads to 'patronising and incorrect solutions'. Instead, this thesis will aim to understand how users can be empowered to make their own decisions, based on their own individual needs, in order to make websites more accessible to them.

1.4 Research questions #

This research will seek to understand the accessibility problems encountered on popular e-commerce websites in the UK and will investigate the causes for these issues. By answering this question, it should be apparent the areas that need tackling to make websites more accessible to individuals.

Research question 1. What are the accessibility problems encountered on popular e-commerce websites in the UK?

Key to this research will be understanding whether personalisation can be utilised by the individual, to make websites more accessible for themselves, given their own accessibility needs. If an individual can personalise an e-commerce website to become more accessible, there may be principles that can be drawn from this project and applied to other websites to make more experiences accessible to as many people as possible.

Research question 2. Would allowing users to personalise an e-commerce website’s user interface cause users to perceive their personalised design as being more accessible than the standard design?

1.5 Research objectives #

For research question 1:

• To conduct a literature review, critically analysing relevant work within the field and contextualise the work.
• To interview developers to understand developer behaviours in development and attitudes towards accessibility.
• To conduct an online study, to understand if personalisation can resolve any of the identified accessibility problems by allowing individuals to personalise an e-commerce website’s design.

For research question 2:

• To conduct an online study, using a custom designed e-commerce website, in order to identify features of a design, that when personalised, will improve accessibility.
• To conduct an online study, asking a small number of individuals with disabilities to complete tasks on a typical e-commerce website, personalising the website through different affordances, in order to identify methods that allow for ease of use and increased accessibility.

1.6 Scope of the research #

The scope of this project will be targeted to website accessibility only, focusing on the user-interface (elements of the content that are accessible to the end-user), as opposed to any accessibility improvements afforded by physical peripheral devices. While this project may draw inspiration from projects that have been conducted with other forms of interactive media, such as mobile applications, video games or physical implementations, this project will not offer accessibility improvements for these mediums.

This project may be limited due to the nature of the research being conducted in the UK, with English (written left-to-right). As such, accessibility problems that arise from the changes in layout and information architecture when using languages with different writing systems will not be covered in this project.

1.7 Project outline #

In order to contextualise this research, the following section, section 2 - the literature review, summarises the difficulty and poor compliance associated with the current web accessibility guidelines before analysing literature in relation to current design and implementation practices and our understanding of accessibility. Interviews with designers and developers provide an understanding of how people in these roles define accessibility in addition to the challenges that they face when trying to implement accessible software. These are detailed in the developer interviews, section 3. Subsequent work then summarises the two studies conducted: Study 1: Bog Roll Business Builder and Study 2: Miss Thread. The first study describes an interactive survey conducted online and provides insight into the type of user interface features that benefit individuals when personalised and analyses the difference in selection between disabled and non-disabled participants. The findings are then implemented into an example e-commerce website titled, Miss Thread, in the ensuing section, providing a summary of testing with a screen reader participant and developers to understand whether the designed method for personalisation is effective and if it could be implemented in other systems. Following these studies, the final section concludes on the work, answering the research questions, commenting on the limitations of the project and suggesting applications of the outcomes of this thesis.

2 - Literature review #

2.1 Understanding the difficulties with current accessibility guidelines and reasons for poor compliance #

To start, we must first establish an understanding of the current state of accessibility guidelines that have been enforced through European Union (EU) legislation (European Union, 2016). To propose areas for improvement, we must understand the groups for which the accessibility guidelines are designed to aid as well as the content covered by the guidelines. It will also be important to understand who the guidelines are designed for, how the guidelines can be tested and adhered to from a development perspective and to then explore whether guidelines are being used as intended. This section will demonstrate that a large proportion of sites are not currently conforming with the Web Content Accessibility Guidelines, suggesting that developers are not creating accessible websites, and will explore reasons for why that may be the case. The goal of this is to identify areas for end-user accessibility improvements by questioning how websites could be better suited to delivering accessible experiences for the user. In comparison, the accessibility problems apparent in e-commerce websites will be identified and analysed to illustrate how the accessibility needs of users are being exploited.

2.1.1 The Web Content Accessibility Guidelines and legislation #

The Web Content Accessibility Guidelines, also referred to as WCAG, are a set of guidelines designed to help make websites perceivable, operable, robust and understandable by anyone, no matter their accessibility needs. The guidelines are constantly being developed and refined by the World Wide Web Consortium (W3C), in cooperation with invited web experts and individuals from companies developing web browsers. The first set of WCAG, WCAG 1.0 (W3C, 1999), were published in 1999 and focused primarily on HTML content. The more recent guidelines are more technology agnostic in an attempt to cover emerging technologies such as those in the augmented and virtual reality spaces. The guidelines include testable success criteria at three different levels (A - the minimum, AA, AAA - highest conformance), to give developers an understanding of how their website must work or respond. For example, the guidelines include recommendations such as ensuring that alternative text is used to provide a description of an image to users that are blind or have a visual impairment or who may not have an Internet connection able to download images; increased contrast between elements will mean that users can read a site without experiencing eye fatigue (University of Washington, 2019). The most recent set of guidelines, WCAG 2.1, were released in June 2018 (Henry, 2018). The EU Accessibility Directive (European Union, 2016) requires that public sector bodies meet the WCAG level 2.1 AA accessibility standard to ensure public sector websites are somewhat accessible and inherently more usable for all audiences, not just those with access needs (Henry, 2019). This legal enforcement requires public sector websites to meet specific guidelines that can be checked and tested, this is somewhat of a first for legislation of this nature.

In comparison, the most recent piece of legislation employed in the UK to enforce web accessibility was the Equality Act 2010, which required that service providers consider “reasonable adjustments” for disabled people (Equality Act 2010, s.2). The EU Accessibility Directive (European Union, 2016) builds upon the requirements outlined in the UK's Equality Act, meaning that both laws must be adhered to. A recent interview with a user of screen readers (Turner and Barrick, 2019) highlighted existing issues with e-commerce websites in the UK. Screen readers are typically used by blind or visually impaired users; a screen reader will scan the text available in a HTML document and synthesize speech (WebAIM, 2017). Turner provides their opinion on general web accessibility when it comes to e-commerce sites in the UK, describing issues such as poor text contrast, small font sizes, menus being difficult to navigate. The user explained that while these features may only seem like small issues, for them, this can make websites ‘difficult or impossible to shop on’. Towards the end of the interview, Turner explains that the community of users with accessibility needs make up an average annual spend of £274 billion which is a similar figure to that identified in an article by the Evening Standard in early 2019 (Silva, 2019) at just over £249 billion. In comparison, consumer product companies spend £6.8 billion in an attempt to capture a small portion of the £80 billion spent by UK shoppers in the 6 weeks before Christmas (Butler, 2019). When comparing the amount of Internet sales against all retail sales in the UK, as of February 2020 (Office for National Statistics, 2020), Internet sales account for 19.6%. This is a five percent increase in comparison to February 2019. The growth of Internet sales as a percentage of retail sales has been consistently trending upwards. As a result of the increasing popularity in e-commerce, it is common to see items for which the only option is to only purchase them online. This is the case with ticketing for events which is done through popular sites such as Ticketmaster and Eventbrite. Clothing retailers such as ASOS operate online only with no physical stores, this means that ASOS's own ranges are only available by purchasing the items through their website. There is no alternative way to purchase items.

2.1.2 Accessibility in the context of e-commerce #

ASOS was one of the websites tested for accessibility by Sohaib and Kang (2016), who were reviewing the accessibility of Australian e-commerce websites. Out of 30 Australian e-commerce websites that were tested, only ASOS met the minimum success criteria for WCAG 2.0 Level A accessibility (the lowest level). These findings align with the WebAIM (2019) report, where 97.8% of websites did not meet WCAG Level 2.1 AA criteria. Sohaib and Kang found that there was a mean of 19.3 WCAG Level A violations per site. The amount of potential problems identified was considerably higher, at 782 per site. Similarly, an article by Gonçalves et al. (2017) evaluated the accessibility of Portuguese e-commerce websites. Their research included automated accessibility testing of websites, a few rounds of expert evaluation and then testing by blind users. Instead of attempting to identify usability problems based on the WCAG, Gonçalves et al. decided instead to conduct user testing with existing websites, to understand how users would actually fare with the tasks. Examples of tasks include selecting specific products, identifying social media links and finalising a purchase through a checkout process. 20 blind users were asked to complete the six tasks, four of the tasks were completed successfully, one of the tasks (identifying the social media links) had a 90% success rate and the task to complete the checkout process had a 30% success rate. The 7 participants that could complete the task required 35 attempts between them. This illustrates just how poor the state of web accessibility is within e-commerce sites.

As explored above, it is apparent that accessibility guidelines are not being met by e-commerce websites. More concerning, are the ways in which websites are implementing features that prey on the needs and goals of individuals. These patterns are commonly referred to as 'Dark UX'. Brignull and Darlo (2019) explain some of the common types of Dark UX patterns, these aptly named types include 'Bait and Switch', 'Disguised Ad' and 'Misdirection'. In regards to accessibility, Gray et al. (2018) expand on the point of 'Misdirection' and refer to it as 'Aesthetic Manipulation' which can be dissected further into 4 separate methods. These methods are ‘toying with emotion, false hierarchy, disguised ad and trick questions’. The authors describe 'toying with emotion' as a use of visuals to evoke an emotional reaction used to persuade a user. Examples of this include checkout timers which encourage users to complete purchases quickly and writing call-to-action copy in an emotive manner to evoke a reaction. This actively goes against advice provided by the UK Home Office (Pun, 2016) when designing for accessibility. The Home Office specifies that when designing for users with anxiety, that developers should not ‘rush users or set impractical time limits’. As a result, it appears that e-commerce websites that do display checkout timers or display that a large number of users are viewing the same product, are doing so to evoke an emotional reaction in the hopes that users will complete a purchase. Mathur et al. (2019) conducted research of 11,000 shopping websites to understand the frequency of dark patterns in use across the industry. Their findings list the 'Low-stock Message', where users are told that a lot of other people are viewing the same product in an attempt to encourage the user to act quickly, as the most frequently encountered Dark UX pattern, identified in use within 632 sites. The second most frequently encountered pattern identified with 393 instances was the 'Countdown Timer' used to tell users that a deal or discount would expire soon, again, encouraging them to act quickly. This shows that e-commerce websites actively implement designs that are the antithesis of the WCAG, with the aim to evoke an emotional reaction from the user, preying on their access needs, in order to convert potential purchases.

2.1.3 Understanding the lack of accessible websites #

WebAIM (WebAIM, 2019) conducted an automated accessibility analysis of the 1,000,000 most visited websites’ homepages, finding that 97.8% of the analysed homepages did not meet WCAG level 2.1 AA accessibility criteria. Automated analysis was completed with the WAVE tool (Utah State University, 2019), which is currently unable to check for items such as the appropriateness of alternative image text (text describing an image provided by developers for those who cannot view the image) or the correct use of HTML 5 semantic elements (developers specify what sections of content relate to, such as a navigation bar or footer). This means that if the 1,000,000 pages were to include manual checks as well as automatic ones, it is likely that more than 97.8% of homepages would be considered inaccessible.

It is rarely the case that actual programming languages do not allow for the development of accessible software, or cannot be developed in ways that allow software to be accessible. One of the possible explanations for this could be that website developers are not aware of accessibility features, nor the importance of ensuring validity of their code (e.g. using semantic HTML elements appropriately) from an accessibility perspective. Power et al., (2012), presented an argument that the WCAG may not provide enough guidance to make websites accessible and suggested the need to move to a design principles approach to improve web accessibility. A design principles approach to web design would see a primary focus on understanding the behaviours of those with different access needs in their use of the web, rather than following guidelines without perceiving the use cases. The piece discusses a number of alarming statistics, such as a 2006 study (Lazar et al., 2004) which discovered that 22% of site owners had no knowledge at all about accessibility guidelines. In this paper, Power et al. selected 16 websites that had previously been used by Disability Rights Commission to test compliance with WCAG 1.0 (Disability Rights Commission, 2004) and asked participants to complete a couple of tasks on the site. If a participant encountered a problem with the task, they were asked to rate the problems perceived severity using a four point scale consisting of ‘Cosmetic’, ‘Minor’, ‘Major’ and ‘Catastrophic’ (Nielsen, 1993, 103). When using the WCAG 2.0 guidelines to categorise user problems that were encountered, 49.6% of the identified problems were not covered by the WCAG 2.0 guidelines. Therefore, automated testing and expert analysis could deem a website accessible based on the WCAG, yet judging by this report, there would still be a number of needs that just are not covered by the guidelines. As new legislation means that developers have to meet WCAG 2.1, if the guidelines do not cover all accessibility problems, it still means that sites may not be fully accessible.

To understand the source of the other 49.6% of problems not covered by the WCAG 2.0, we can look at what the guidelines do not cover. Lopes et al., (2010) argues that the WCAG are not tailored to an individual user’s needs or goals, more so they are tailored towards particular disabilities. While this makes sense from a regulation perspective, it does not offer guidance as to the changing context of different situations and the differing ability of individual users. The Government Digital Service (2019) advises that developers think about accessibility as a concept based on the needs and circumstances of users when accessing a service. The Government Digital Service article provides examples where a user’s ability would be affected, including ‘location - they could be in a noisy cafe, sunny park or area with slow wifi’, ‘health - they may be tired, recovering from a stroke or have a broken arm’. These examples depict how difficult it can be to understand user needs and user goals as they could be constantly changing and as such, users are dynamic in their skill and ability levels (Gregor & Newell, 2001). Without this understanding, creating guidelines that work for individuals cannot be created. Developers who wish to create accessible websites will look to legislation to see what is required, they will then implement the WCAG as required by law. However, they may not stop to question whether the implementation suits individual users of their content. Without this, they may be developing websites that are not accessible despite their best intentions.

2.1.4 Summarising the difficulty with accessibility guidelines and reasons for poor compliance #

In this section we have identified that more than 97.8% of website homepages may not be accessible to users when comparing sites against the WCAG (WebAIM, 2019). Furthermore the WCAG do not tend to account for all accessibility issues, in fact 49.6% of accessibility problems encountered by users are not accounted for in the WCAG (Power et al., 2012). For the majority of problems discovered that are not catered for within the WCAG, these could be problems that relate to the individual needs or goals of a user as the guidelines tend to focus on guidance for specific groups of users’ needs (Lopes et al., 2010). As the very definition of accessibility is that the needs of a user are met at the point of accessing a service, it is clear that users’ needs and goals are dynamic (Gregor & Newell, 2001) as individuals use services in different ways through changing contexts (Government Digital Service, 2019). Looking in particular at the e-commerce space, we have discovered that Dark UX practices, such as low stock messages and countdown timers, are commonplace within the industry (Mathur et al., 2019). These practices exploit the access needs of users, doing so in the hopes of converting more sales. In order to understand how accessibility can be better implemented, we must seek to understand development methods for front-end use. What values are deemed important when it comes to user interface design and how can we grow or adapt existing methods to better suit the accessibility needs of all users on the Internet?

2.2 Development methods for improving accessibility through the user interface #

In order to understand areas where accessibility could be built into developers' practices and development methods, we need to understand the frequently used design methods in recent years. This section will cover the use of media queries, a technical implementation used by web developers to tailor the user interface of websites at different display sizes, which is becoming increasingly complex given the expanding number of screen sizes. It will also introduce design systems, a development method and tool with the goal of creating consistency throughout websites and we will uncover why consistency helps to make user interfaces more accessible. Following on from design systems, we will look at the more recent development, design tokens, allowing designers to implement core user interface building blocks which can propagate changes throughout user interface elements. We will then seek to critically analyse these methods with the goal to understand how developers may go about introducing increased accessibility in their sites, without increasing workload or adding additional processes.

2.2.1 Contexts of use and resulting development trends #

A trend towards responsive design began in 2010, when Ethan Marcotte defined the term as the use of flexible grids and images to create designs that respond to different screen sizes with the use of media queries (Marcotte, 2010). In 2011 Smashing Magazine, a website with 3,000,000 monthly page views, published an article detailing why developers should begin to use responsive design (Smashing Magazine, 2011), an approach whereby developers can make the existing site ‘flexible’ and fit for mobile and tablet devices (Andrews, 2018). The article offers approaches such as making use of percentage sizes as opposed to traditional static pixel values, so that elements can scale; using additional style sheets paired with media queries, so that developers can specify different styles to be rendered when the browser size meets those rules.

The recent adoption of new layout methods, such as CSS’s Flexbox (World Wide Web Consortium, 2018) and Grid (World Wide Web Consortium, 2017), specified by the CSS Working Group show an acknowledgement that design has not been flexible enough in the past to create responsive websites, without developers adding in numerous media queries. These new layout methods offer developers the power to be able to tell the browser how to adapt content without having to specify different media queries for different screen sizes. This development seems to acknowledge that the differing contexts of use and diverging screen sizes (Figure 1) have made it too difficult for developers to solely use media queries to adapt the layout of content. The Internet of Things is an umbrella term given to the array of devices that have the capability to connect to the Internet, with the end goal of allowing these devices to be able to automatically communicate with each other (Commission of the European Communities, 2009). The recent development in Internet of Things (IoT) technology, means that more and more devices are able to access the Internet with a browser. An example of this would be Samsung’s Family Hub fridge that allows users to browse the Internet from a screen on the outside of the fridge door. New wearable technologies such as interactive smart watches allow users to browse the Internet on their watch screens. Game consoles such as the Nintendo 3DS and Playstation 4 come equipped with browsers to allow users to browse the Internet. It is hard to imagine that a single developer would be able to test their designs across all these systems or develop media queries to match all these devices. The workload seems too high and even conceiving the use case for doing so may seem extremely minimal. However, from a user's perspective when accessing sites through these devices, they will receive an experience less than that they would have had when browsing from a desktop device. It is also important to remember that accessibility and context of use may differ when using these devices. If a user is accessing the web through their smart watch, they may be on the move, walking past people and trying to concentrate on getting to their destination and not focusing on the text on their watch. A user may be viewing a recipe on their fridge while baking in the kitchen, trying to pay attention to their baking and intermittently checking the instructions. It seems completely impractical that a developer would be able to check how their website performs in all of these different scenarios as the context depends entirely on the individual using the site.

In order to improve the user’s experience between different contexts of use and across different websites, Pickering (2017) believes it is important for the user interface to be consistent with not only itself, but also with similar, frequently used interfaces. To ensure consistency throughout products, companies have produced documents that explain how their user interface elements should look and how they should be used. These are often referred to as ‘Design Systems’ or ‘Pattern Libraries’. One of the most notable approaches to this methodology is by Brad Frost, who proposed the idea of Atomic Design (Frost, 2016). This approach requires designers focus more on the consistent design of user interface elements which can be put together to build pages, instead of thinking about building pages first. This modular approach to design means that by designing the smallest elements of user interfaces first and then slotting these into larger groups to build up UI components, the smaller ‘atoms’ are propagated out throughout the system. An example of this could be a search bar and filters for discovering events at a local venue. Instead of going and designing the search page and implementing it straight away, using atomic design, first we would design our buttons and drop-down lists, our atoms. Next, we would design our search bar which consists of a text input field and a button, together these become a molecule. Pairing our search bar with our filter atoms creates an organism. This can continue to then create reusable templates and pages. This approach is illustrated in Figure 3, Frost’s Atomic Design approach to the Instagram application (Frost, 2016). By utilising atomic design and design systems in this way, designers and developers can decide on the best design for a UI element which can then be implemented once. If developers can ensure that their atoms and molecules are accessible, accessibility should then be propagated out across systems. Jina Bolton expanded on this with her work at Salesforce on design tokens (Bolton and Levine, 2016), which clearly define fundamental user interface elements such as colours and typography, used as building blocks for UI elements. A number of generators have appeared online, which can take values and then generate several different files, providing design tokens for use in Android applications, iOS applications and websites. Using design tokens in this way helps to cover aspects that Atomic Design does not cover, such as ensuring consistency in the use of font sizes across different elements. Design tokens used in this way allow for easy propagation of core user interface features throughout a whole design system, providing designers with an increased control of visual consistency. If different individuals' needs could be captured in a series of design tokens, when applied, the changes to the entire design could be propagated out across the whole user interface; this could provide all the benefits of consistency while accounting for the individual’s access needs and goals.

2.2.2 Consistently failing users #

These approaches aim to make websites usable and accessible by ensuring consistency across devices. Interactions on the website will not require re-learning, all elements should work consistently. However, consistency does not always mean that accessibility will be improved. It does depend on features being accessible when implemented. Implementing designs that have poor accessibility consistently, does not increase accessibility. A key example of this has been identified by Norman (2019) who argues that Apple's designers make text within Apple’s iPhone operating systems extremely hard to read. The iPhone operating system is based on Apple's Human Interface Guidelines (Apple, 2020), which ensure consistency throughout their software. This means that text size, colour contrast and spacing are all accounted for and will appear consistent throughout their systems. ‘The designers at Apple apparently believe that text is ugly, so it should either be eliminated or made as invisible as possible’ (Norman, 2019). Norman discusses that for an older person, the designs break fundamental design rules in terms of being understandable and usable. Norman goes on to advocate that the practice, inclusive design, should be adopted by all designers as it has the potential to make everyone’s lives easier. Norman cites examples where users who may not typically experience issues in relation to accessibility, suddenly due to a change in health, location or context experience access issues similar to those previously discussed in this research. These include the user being unable to read text when their device is in direct sunlight or an athletic parent carrying a baby with one hand, shopping in the other and trying to open a car door. Norman even goes as far to suggest something sounding very similar to personalisation, posing the question, ‘wouldn’t it be nice if the display, whether cellphone, watch, or tablet, could switch to large, higher contrast lettering?’.

2.2.3 Summarising development methods for improving accessibility #

To summarise, developers have been adopting different methods to create responsive designs (Andrews, 2018), moving away from frequently used media queries towards methods that allow for adaptive designs that respond to different screen sizes without having to specify all the different screen sizes, which are increasingly diverging. Not only does this seem to suggest that developers are not able to keep up with the development of responsive websites to fit the different screen sizes, but that developers are less sure of the context of use for their sites as more devices with web browsers are released and adopted by the public. To attempt to ensure consistency, design systems or pattern libraries have been developed to create consistently designed components for use within organisations. Frost’s approach to this is modular (Frost, 2016) in the way that the approach advocates for starting from the smallest possible UI items (such as a button or an input field) which can then be built up and inserted into larger, more complex elements. The benefit of doing so is that changes will propagate out throughout a system’s elements, meaning a developer would only have to update an ‘atom’ element once, with all other components using this ‘atom’ then receiving the changes. From an accessibility perspective, an ‘atom’ could be tested and once deemed accessible, could be used universally across a website, without having to update everything individually. This would save development time and effort, while reducing the amount of testing required. Design tokens build upon this concept further by introducing tokens which capture the fundamental building blocks of a user interface design, such as colours, fonts and font sizes (Bolton and Levine, 2016). Once updated, as you would expect with design systems, these changes propagate out to all components without the developer having to manually update anything. When considering the governance that large companies experience when controlling and updating design systems (Churchill, 2019), paired with Norman’s critique of current UI design (Norman, 2019), it seems apt that a user should be able to specify their own needs and goals in a format that can be accepted and allow for the personalisation of a user interface. Design tokens could then be used to capture user needs, which could then propagate throughout the system without additional development required by developers or designers.

2.3 Adaptable user interface solutions, investigating similar work done in the same area #

The final section of this literature review will seek projects that have allowed for the personalisation of websites. The majority of academic work in this space is related to the automatic adaptation of user interfaces, based on different information that systems can accumulate about a user's context of use and/or accessibility needs. Some of the methods for capturing different information include communicating with a device’s operating system to get values such as the brightness of a display (Yigitbas et al., 2017) as well as physically surveying users to get a sense of their accessibility needs (Ji et al., 2017). These approaches differ vastly from allowing the user to customise the interface themselves, based on their own needs. As a result of this, the aim of this section will be to identify areas in which these projects could have been improved in relation to their use of customisation in order to better serve user’s needs and goals.

2.3.1 An overview of adaptable interfaces #

Adaptable user interface solutions attempt to automatically customise user interfaces based on the information that automated systems can scrape about the user in question. Typically, this information tends to be contextual, with examples such as gender, geographical location and age. Based on this contextual information, systems will then group users, as defined by developers, so that they may see a design that the developer believes to be more relevant to an individual’s needs. While the attempts in which to provide the user with a more relevant version of a user interface differ from this thesis, the aim for both this project and these adaptable user interface solutions are the same - to provide the individual with a design to better meet their needs.

‘While each user deserves a personalized interface… there aren’t enough ethnomethodologists and designers to manage, interpret, and respond to so many studies’ (Weld et al., 2003), were the beliefs of those at the University of Washington, IBM and Google; starting on a project to automatically personalise user interfaces in 2003. However, the paper goes on to say that most users ‘fail to customize effectively’, speculating few users are comfortable with methods of programming. The piece fails to explore other methods for customisation. Weld et al. describe previous attempts at customisation through the use of programming as opposed to natural language interfaces, as well as various models that can be used and improved upon to predict user behaviour. The paper concludes by finding that at the time, the project was constrained by the lack of methods for adaptation and customization. Weld et al. also discovered that a device should only display capabilities available in the current context and that if a user interface were to automatically personalise itself, that a user should be able to ‘control the adaptation process at any level’, at which point it begs the question, why can a user not personalise the user interface themselves?

Stuerzlinger et al. (2008) provide a set of criteria for adaptable user interfaces. Adaptable user interfaces should feature: (1) fast, simple, just-in-time customization; (2) not only global customizations, but also local ones; (3) deep customization (the ability for the user to define their preferences directly, not just be able to select options from presets); (4) cross-application customization. Although these criteria are based around desktop applications, I believe that they could be applied to websites or other forms of interactive media personalization, due to their flexibility. The examples given in the paper, as well as the current implementation in modern web browsers, focus on global customizations (i.e. changing the font size for all websites that you visit). To ensure conformance with criteria 2 (not only global customizations, but also local ones), it makes sense to first utilise the user's global customisations set in the browser (font-size, font family, specified colours) and then personalise these for individual websites (local customizations). It will be key to understand the affordances that will be needed to highlight that customisation is allowed, as well as how and when users will want to customise. In this project, I will attempt to achieve criteria 1-3, however I believe that for the scope of this project, criteria 4 (cross-application customization) will not be met. To advance this piece or as part of future work, criteria 4 could be considered.

2.3.2 Summarising the research into adaptable user interface solutions #

In summary, this section has presented existing research that highlights the same issues as argued in this literature review: that users require their own user interface, personalised to their individual needs and goals. However, the methods for capturing user needs, discussed in this section, would mean additional work on top of a developer’s existing workload. The methods utilised would require developers to create criteria for when the adaptation will occur, this also means that they will have to tell the system how to adapt and for which users the adaptation will occur. The findings of Stuerzlinger et al. (2008) should also prove a solid basis to design personalised affordances from, ensuring that the system is fast, simple, global and local in scope and allowing for in-depth changes, all of this should be in place consistently throughout the system.

2.4 Conclusion #

To conclude, this literature review argues that users can receive a more accessible experience by developing a system that can allow the user to define their own needs and their goals through the use of a personalisable user interface.

By identifying shortcomings in the WCAG, where the guidelines are developed for groups of users with different needs, the guidelines do not recognise the needs of individual users (Lopes et al., 2010). This paired with a lack of use of the current WCAG means that the amount of websites that have at least one inaccessible page is above 97% (WebAIM, 2019). However, we can build upon this definition of web accessibility. Using the definition for accessibility provided by the Government Digital Service (2019) and taking into account the issues that Norman raised (2019), accessibility should be understood as the needs and goals of all users on the Internet which can change depending on the context of use. Users are not static in their abilities (Gregor & Newell, 2001), they are constantly changing and this can be as a result of minute factors outside of our control. To be accessible is to take into account a user’s differing levels of abilities and skills and to deliver an experience that caters itself to the individual and is still easy to use.

As we understand the movement from website designers to create more consistent user interfaces, which require less learning and are consistent within themselves and when compared to external sites (Pickering, 2017), we can start to design user interfaces that are easily recognisable and can be easily understood. As identified earlier, making use of design tokens (Bolton and Levine, 2016) as the fundamentals of a user interface (colours, fonts, font size) and opening up these values as options for users would allow for personalised changes that propagate throughout an entire system, without increasing the workload for a designer or developer.

Finally, identifying existing work relating to delivering the user with more relevant user interfaces has allowed for an understanding of what has worked well in the past and what could be improved. Based on the research in this literature review it seems that adaptable user interfaces may not have been successful due to the increased workload that it required from developers and as the overwhelming majority of websites are not accessible, it seems hard to believe that developers would be willing to spend a lot more time to make websites accessible. However, Stuerzlinger et al. (2008) provide criteria that accessible user interfaces should follow, providing a foundation for this project to begin from.

3 - Interviews with web designers and developers: Understanding attitudes towards accessibility #

3.1 Introduction #

The material covered in the literature review has highlighted that 97% of the website home pages tested did not conform to Web Content Accessibility Guidelines (WCAG) (WebAIM, 2019) and that 22% of website owners interviewed had no knowledge at all about accessibility guidelines (Lazar et al., 2004). These problems illustrate that there may be issues such as a lack of understanding or a lack of awareness of the WCAG present within the website development community. These issues are still prevalent, at a time when guidelines are being enforced by legislation (European Union, 2016), requiring public sector websites to meet WCAG 2.1 AA.

In order to be able to better understand the cause for the lack of accessible websites, the interviews conducted provide an understanding as to how developers define accessibility, the challenges that they face when creating accessible designs and opportunities or challenges that they see for accessibility in the future. As such, evaluation of the responses provides an insight as to why access problems are encountered on websites and, through a critical analysis of responses, it is possible to identify methods and opportunities for implementing personalisation. Additionally, these interviews provide the opportunity to understand directly from developers the causation for the lack of accessible websites. The literature discovered and analysed in the previous section did not provide much insight as to this causation, which is important to understand so that it can be improved upon.

To conduct these interviews, 5 participants, each with different roles in the website design and development field, were interviewed. A semi-structured approach to interviews was taken, to allow for the ability to explore different concepts raised by participants' answers (Wilson, 2014). Initially, the plan was to interview participants in person; following which, the participant could be shadowed to provide a more in-depth analysis into their design and development methods. However, due to the Covid-19 pandemic, this was not possible. Instead, only one interview took place face-to-face, another via video conferencing and the remaining three by email. Those conducted by email led to an asynchronous approach, meaning that there was more time to analyse responses and reply with further questioning.

3.2 Goals #

As a result of the analysis conducted throughout the literature review and the knowledge gaps identified, the following goals were developed:

• To learn how developers define accessibility. The lack of understanding of accessibility seems apparent in the sector, evidenced through statistics such as 22% of site owners not being aware of accessibility guidelines (Lazar et al., 2004). By understanding the individual's definition, it may provide context as to the way that accessibility is being implemented and who it is being implemented for. This goal may highlight accessibility features that are being implemented and as a result, features that are inaccessible. This will provide more answers to research question 1 and may uncover other accessibility issues not discovered in the literature review.
• To understand challenges faced by developers trying to implement accessible software. Essentially, this goal is to understand some of the causes behind 97% of websites containing at least one inaccessible page. Is it as Power et al. (2012) proposed, that the Web Content Accessibility Guidelines (WCAG) do not provide enough guidance for those implementing websites, to understand what they need to do to make content accessible? This goal may have two parts as there could be both technical limitations (i.e. developers cannot understand WCAG) as well as pressure from other parties (i.e. the business wants the product to be in production as soon as possible with accessibility not being a key focus). Identifying challenges faced by developers should lead into identifying solutions that would work for developers.
• Identify potential opportunities or challenges for accessibility in the future. The majority of the literature review covers critiques of current or previous guidelines, but do not offer much in the way of future work. Understanding developers' thoughts on challenges in the future, regardless of the type of challenge, may provide valuable information for research question 2.

Interview questions can be found in the Appendix, section 7.1.

3.3 Participant roles and coding #

For brevity, individuals are referenced as their abbreviations throughout the following sections. The abbreviations used can be found below and relate to the roles of the 5 participants.

• DPDM - Digital Projects Design Manager
• UXRL User Experience Research Lead
• AS - Accessibility Specialist
• UIDL - User Interface Design Lead
• EFWD - Educator and Freelance Web Developer

To analyse the data provided by participants, a round of deductive qualitative coding was employed on the transcribed interviews. This approach was adopted to allow for a more in-depth analysis of the knowledge gaps. For a deductive coding approach there must be a set of predefined codes, the codes used to analyse these developer interviews are a result of the interview questions designed to address knowledge gaps as well as the goals for this section.

• Accessibility opportunities
• Challenges when designing accessible websites
• Measuring success
• Priority planning
• Requests and reporting
• Role
• Testing

A description for these codes can be found in the Appendix, section 7.2.

The data was coded, following methods from Rubin and Rubin (2005, 201-223) in order to further understand the issues around accessibility by identifying concepts and comparing different accounts and themes. The coding was conducted using an application called Taguette which works locally on a user's machine (no information is sent elsewhere) and allows the user to code any imported transcripts. Once coded, that information is then collated into individual views for each code, making comparison much easier.

3.4 Working towards a theory #

When looking through the different coded categories and analysing the themes and concepts that have emerged, there are key strands that run across the different themes.

The main strand can be identified as the idea that business goals are being prioritised ahead of the user's needs. This issue stretches across accessibility opportunities, challenges faced when designing accessible websites and can also influence the level and scope of testing that is conducted on products.

In general, this concept adversely affects the experience delivered to all users. The quote, ‘... a product owner is trying to flog you [a] loan or a mortgage. You know their objectives are for more people to click this button and to go through and convert on this journey, rather than, we want people to make the right choice for their finances…’ (DPDM), provides us with an understanding of a business' priorities. In the example given, the user's goals may not align with the business'. The user will want to make the right choice for their finances, yet may not know what that choice is. Regardless of this, the business’ goals are to increase sales and further promote their products and as such, they will attempt to continually sell additional products to the user. As such, the business prioritises its goals above the user’s needs. As the business does this, it may even create designs that prey on disabled users, as evidenced during the literature review. The business may supplement their marketing and promotion efforts with dark UX patterns, using copy to invoke an emotional reaction with users or may apply pressure by displaying low stock messages, all adversely affecting users with anxiety. This aligns with the general thoughts of interview participants, with one interviewee commenting, ‘I’m also increasingly concerned about the political motivations of some of the tech industry, where right-wing free-market principles seem to be in conflict with the ethical, human-rights principles that should underpin inclusive design…’ (UXRL).

As the goals of the business grow and change, there's the need for additional functionality and existing products with the challenge of beating competitors to market leading to short deadlines and faster projects, 'There’s a tension between adding more functionality and providing a simpler user experience—too many people value the former over the latter, and complexity makes solving accessibility more challenging'. As the business wants to increase functionality and expand products to capture more business, it develops products quickly, de-prioritising usability and accessibility . When discussing with participants the challenges of designing accessibly, one of the participants highlighted that there is not a challenge if they are involved with a new project from the start, however if it is a project that has accessibility issues and the implementation has been completed before, then the constraints and challenges are much greater. As such, accessibility faces a losing battle from the start. Businesses do not consider accessibility when developing projects, waiting until a redesign or a legal challenge before taking action, at which point the constraints in place make creating accessible interactive media much more of a challenge and increases costs as it takes more time.

As the demand for more functionality increases, the tools, frameworks and libraries that developers use need to allow for quicker and easier development. As evidenced, tools such as React (Facebook Inc., 2020) focus on providing a better developer experience with little focus on usability or accessibility recommendations. As discovered from the literature review, tools, frameworks and libraries that provide the best chance of allowing for accessible development are those that plan and integrate accessible development from the start. In modern cases, the developer experience is being considered from the start with little regard to the accessibility allowances of the project. This negatively impacts the chances of accessible websites, but benefits the business as these technologies reduce implementation time and therefore the cost of development.

For those that are trying to implement accessibility at their companies, the definition of accessibility has a different meaning to individuals. To some web accessibility purely means meeting the WCAG to a sufficient level, such as WCAG 2.1 AA. Accessibility consultants understand that the WCAG are criteria to ensure that websites should work correctly with assistive technologies and do not ensure an accessible experience to users with disabilities.

The difficulty to understand WCAG and the needs of disabled users means that even those with the best intentions are not able to accurately convey the needs of disabled users. As a result, websites will continue to not be accessible unless there is a significant change in culture as suggested by the interviewees. Interviewees believe an opportunity for accessibility to be legislation that will challenge businesses and require them to implement accessibility or face legal action. This legislation will challenge the business and force their goals to meet the needs of individuals.
However, the participants acknowledged that understanding the new legislation, as well as how it will be enforced, is difficult. As a result, it is difficult to understand whether it will have the effect as the Domino's Pizza case (Robles vs Domino's Pizza, LLC, 2019), forcing companies to make their websites accessible, as many of the interviewees had hoped.

The Robles vs Domino's case was frequently referenced by participants. It is a case in which a blind individual (Robles) could not use the Domino's app and website as the content was inaccessible and as a result, sued Dominos for failure to comply with the Americans with Disability Act of 1990 (commonly referred to as the ADA). Initially, the lawsuit was dismissed in 2017 after it was argued that while the ADA did apply to the Internet, there were no clear guidelines enforced that explained how websites should be implemented in order to comply with the ADA (Level Access, 2020). However, the case was taken to the United States Court of Appeals for the Ninth Circuit, where the dismissal ruling by the district court was overturned (Robles v Domino’s Pizza, LLC, 2019), meaning that the lawsuit will now proceed again back in the district court. In a lawsuit there is a discovery period where parties can request 'books, records or other documents for inspection' (American Bar Association, 2019). As such, this case may reveal internal attitudes towards accessibility within a large private company.

This theory of prioritisation of business goals over the users needs is grounded in the responses of individuals who specialise in website design and front-end web development. To further understand this concept and prevent the case being one-sided, other stakeholders from businesses should be interviewed and given the chance to explain their personal points.

3.5 Conclusion #

In conclusion, the developer interviews provided a great deal of context towards the challenges facing web accessibility. In order to relate these findings to the rest of the research, we will examine if the goals for this section have been met.

3.5.1 Goal: To learn how developers define accessibility #

There is no single definition for accessibility used by those interviewed. The needs of disabled users do not tend to be directly understood by designers and developers. Instead, people in those roles tend to look towards the WCAG and have an understanding that if they are able to meet a suitable level such as WCAG 2.1 AA, that their products will be inherently accessible and usable to a large audience. This is not the case. As evidenced in the interviews, for products to be accessible they need to be tested by disabled users and iterated upon until users with disabilities encounter no issues when testing them.

A lack of understanding or general definition is problematic. If people developing websites do not understand accessibility, they stand very little chance of creating products that disabled users can use. This may go some way towards providing a reason as to why so few websites are accessible.

3.5.2 Goal: To understand challenges faced by developers when trying to implement accessible software. #

The challenges faced by developers trying to implement accessible software include a lack of understanding of accessibility needs (as highlighted above) and the requirements by businesses to increase functionality in short time frames. The latter explains the recent focus on the developer experience and highlights the challenges that developers face to quickly turn around work. Therefore, any personalised accessibility solution cannot greatly increase the workflow for developers as it stands no chance of being adopted and used.

3.5.3 Goal: Identify potential opportunities or challenges for accessibility in the future. #

To again highlight the issue of business goals taking priority, the opportunities for accessibility in the future given by interviewees generally related to actionable accountability. This highlighted how businesses fail to recognise the needs of disabled users and as a result, participants hoped that legislation and the fear of legal action would cause businesses to create accessible websites.

Challenges all seemed to be directly linked to the opportunities. The participants would explain challenges, this is where the Domino's Pizza accessibility case (Robles vs Domino's Pizza, LLC, 2019) would be mentioned, explaining that the opportunity would be to change the culture within the industry through holding businesses accountable.

4 - Study 1: The Bog Roll Business Builder #

4.1 Introduction #

When styling the design of a website's content with the CSS programming language, there are 533 distinct properties (W3C, 2020) to choose from. These properties relate to different aspects of a design such as colour, size, position and behaviours of the elements on the page. When writing CSS, elements on the page are targeted with selectors and using these selectors, developers can apply multiple properties to achieve their desired styling. The combination of a selector and property creates a 'rule' (Mozilla, 2020). Analysing the recent version of the popular CSS framework (State of CSS, 2019), Bootstrap (Bootstrap, 2020), shows that there are 1189 rules to achieve their desired styling. When combined, these 1189 rules build the user interface for one of the Internet’s most used frameworks. This illustrates the complexities and scale of considerations that must be made when designing reusable frameworks.

In order to allow an individual to be able to personalise the style of a website, we need to understand which properties offer the most benefit to the user when personalised. For example, if users of a website struggled to read the text due to poor legibility (one of the most frequently encountered access barriers) (Brownlow and Williams, 2020), it would make sense to allow aspects such as the font style and colour to be personalised. However, there may be other properties that may be good candidates for personalisation. Considering Hick's law (Hick, 1952; Hyman, 1953), which describes how the time to make a decision increases with the number of options and complexity of those options, providing a user with the option to personalise all 533 properties would be too time consuming. Instead, there needs to be an understanding of the features of a website's design that, when changed, greatly enhance the user's experience taking individual access needs into account.

The aim of this study was to understand whether personalisation would benefit all users in general or specifically users with access needs, through the collection of both quantitative and qualitative data. Given the timing of this study, beginning during the midst of the UK's COVID-19 lockdown, the entirety of the research had to be conducted online. With this in mind, an interactive, engaging, study was designed to be independently completed within a modern web browser (such as Google Chrome, Firefox, Safari). This study was designed to be comical and playful, as to attract interest and increase the chance of the website being shared across social media so that more people would discover it and take part. Ethical approval for the project was obtained through the University of York - Theatre, Film, Television and Interactive Media’s ethics process and adhered to throughout this study.

4.2 Similar projects and inspiration #

There were two main sources of inspiration for this study:

• User Inyerface by Bagaar (2020)
• Is this a Sandwich? by Sarah Drasner (2020)

Both of these projects became popular on social media throughout the first few months of 2020, being shared for their novelty and the interactions provided to users.

User Inyerface is a website that provides users with the challenge to complete a form within the web page as quickly as possible. The challenge is introduced on the landing page, where users are presented with a large green button, with the text ‘NO’. An experienced web user may assume that a large green button with large, bold, text would be a primary call-to-action and they should click it to continue. However, this is not the case. The link to the next page can be found in the line of text below the green 'NO' button which reads ‘Please click HERE to GO to the next page’. The word 'click' is underlined, with the words 'next page' in a light blue colour. Again, given the affordances employed within the design, an experienced, sighted web user may believe that one of these options is the link to the next page. Yet instead, the user must click the word, 'HERE'. The website constantly deceives the user by manipulating common design patterns, throwing the user off by manipulating affordances and interactions to present a confusing, almost unusable website.

Is this a Sandwich?, challenges the user by showing them pictures of sandwich-like food, asking them to decide whether the food could be classed as a sandwich or not. The user answers by clicking 'YES' or 'NO'. After answering 19 questions, the website presents you with your 'score' and ranks your opinion on a scale ranging from 'Chaotic Good' to 'Lawful Evil'. Once you have your results, the website makes it easy to share your results, with a large 'Tweet it!' button, prompting the user to share their results on social media. Clicking the button generates a tweet, pre-filled with your results and a link to invite others to play.

4.3 Designing the Bog Roll Business Builder website #

To understand the features of a website’s design that offer the most benefit to individuals, in relation to meeting their access needs, a study was conducted where users could design a toilet roll retail website. The website asked them, feature-by-feature, what their preferred way to style the content was, allowing individuals to create a design to meet their needs as an individual.

4.3.1 Initial considerations #

The aim of this study was to understand the features of a user interface that when changed, benefit the users the most, providing further insight into research question 2. Given that the literature review (section 1) provides no framework for conducting such a study as there is a lack of published literature on the subject, in conjunction with the sources of inspiration, the UK Home designing for accessibility posters (Pun, 2016) were used as a framework. Reviewing these posters provided a key focus around 5 key changes to the user interface, aimed at improving the accessibility of the design for users with differing levels and combinations of disability. The 5 changes to the user interface extracted from the posters were:

• Changing the language (Users on the autistic spectrum, users with dyslexia, users who are deaf or hard of hearing)
• Changing colours (Users on the autistic spectrum, users with low vision)
• Changing the layout (Users on the autistic spectrum, users with dyslexia)
• Changing the interactions (Users with physical or motor accessibility needs)
• Adding additional information (Users with anxiety)

The ability to personalise these user interface features were the focus of this study, where a fun website was created allowing the user to select options for how the website is displayed. The questions that were presented to the user in this website can be found in the Appendix, section 7.8.

4.3.2 Enabling live customisation #

In order to allow the participant to understand the options that they were choosing between and to display the options within the context of a shop’s user interface, a section of the study site was used to provide the emerging design to the user. This 'live' design was based on example content affected by the user's answers to questions and styled to look like a real website. For example, when a user picked the ‘larger’ text size in response to the ‘How big should the font on your e-commerce site be?’, the text size in the 'live' design would change to large text. The design updates almost instantly, as the participant selects options from the form without the need for the page to reload. To provide this 'live' view of an example website, the implementation used a recent addition to web browsers, CSS Custom Properties.
Using CSS Custom Properties

Reusable values are a recent addition to the CSS programming language. Typically, when writing CSS, there will be repeated values for properties such as colours and border styling. CSS custom properties allow for the abstraction of these values, which can then be stored in a variable to be used throughout the code (Mozilla, 2020). This idea is not new, with CSS tools such as Sass (a CSS preprocessor, providing a variety of features such as variables and functions) providing similar functionality (Sass team, 2020). However, a feature that makes CSS Custom Properties stand out is that they can be updated within the browser, taking immediate effect and providing instant feedback to the user (Dodson, 2016). In addition to this, the value of a CSS Custom Property can be changed when a class is applied to a HTML element. hen an option has been selected, a class can be toggled on an element to update the styling immediately in the browser which can be achieved with a single line of JavaScript code

4.3.3 Storing information #

A minimal approach was taken to storing data, ensuring that only data relating to the purpose of the study was captured in the live site. Information relating to participants’ responses to the design of their website was inserted into a MongoDB database, using Netlify functions to transport the data securely. Information was then pulled in a similar way from the database to present the most frequently selected options in a design to the participant. Further contextual information explaining the participants’ choices once they had finished creating their design and demographic data was collected using a Google Form embedded in the study site. As some of this demographic data related to personal information such as disabilities, Google Forms was used to ensure that personal and special category data was stored securely on the University of York Google Drive and therefore compliant with the General Data Protection Regulation (GDPR) 2018.

4.4 Accessibility considerations #

4.4.1 During the design #

Semantic HTML

In order to ensure that the project was accessible, semantic HTML5 elements were used. Semantic HTML5 elements include sections, footers, fieldsets and also require the correct structuring of heading elements to ensure that participants would be able to correctly navigate the page and understand the content. Providing the questions to participants in a HTML5 form, using radio button input fields correctly marked up with labels (describing the input), meant that all users should have been able to complete the form. To group questions and answers and create a semantic link that could be understood by all users of the site, questions were contained within a HTML fieldset, utilising a legend for the question itself and radio buttons and labels to provide the different options for each question (W3C, 2019).

Additional considerations

JavaScript was used to display a single question to the user at any given time. The participant could then answer by selecting the radio button aligning with the value that they wished to choose. Once selected, as all the elements within the page were standard HTML5 specification, browsers are able to acknowledge that a radio button has been selected, so participants using assistive technology (such as a screen reader) will know that an option has been successfully selected. As the user selects the item, JavaScript toggles the relevant class on the HTML body element, causing the relevant CSS Custom Properties value to change. In turn, this updates the 'live' design, providing users with an up to date representation of the user interface they have been creating based on their selections.

Sighted participants are able to see, visually, the changes made to the design as the design updates on their screen. To ensure that participants who are blind or visually impaired and using a screen reader device can navigate the designs, an additional skip link is provided below the fieldset for each question. Selecting this will place the participant's focus at the start of the 'live' website view on the page, so that they may easily test their design, without having to navigate around the page looking for it again.

Another consideration was to provide clear feedback when interactions took place. ARIA live regions were used to supplement the dynamic content displayed with JavaScript, notifying assistive technologies of the visual change (Mozilla, 2020). For example, when a participant selects the ‘Clear select option’ button, non-disabled people will be able to see visually that the option has been cleared. However, for blind or visually impaired users, the message ‘Your selected option has been cleared’ is displayed on screen by some JavaScript; which is then announced with the ARIA live region property set to 'polite' on the element. Setting the aria-live attribute to polite means that the content will be announced but will not interrupt the screen reader and what it may be currently announcing.

4.4.2 Accessibility testing #

Automated testing

Three tools were used to conduct automated testing and all were used consistently during development to check for obvious errors and mistakes, these were:

• The W3C Markup Validation Service (W3C, 2012)
• axe - Web Accessibility Testing Chrome Extension (Deque Systems, 2020)
• Lighthouse (Google, 2020)

Testing with users

As a result of the gaps left by areas that automated testing tools were unable to cover, participants with a range of different access needs due to varying disabilities were recruited to help understand their experiences and to identify any accessibility issues with the developed site (as discussed in section 3.5.1). Participants were recruited by posting messages about the planned testing of the site on Twitter. Testing the website was planned to take roughly an hour to complete. Participants were thanked for their participation with a £20 Amazon voucher. Those that took part were provided with a link to the website and asked to create their own design, following which, they had to complete a longer version of the Google Form, see the Appendix, section 7.9. This form included an additional section asking the participant if there were any problems with the usability of the site and understanding the aims of the website. In the end, three participants were recruited, one of the participants is visually impaired and uses ZoomText; another participant is blind and uses the NVDA screen-reader, navigating websites with a keyboard; the final participant identified as having a disability but did not wish to disclose any further information about the disability.

None of the participants recorded any problems with the accessibility or usability of the site, nor understanding of the aims of the study. The participant using the NVDA screen reader stated that they thought ‘the options were clear, and the use of buttons to choose the options and then see the different results worked well’. Following the completion of this testing, the website was opened up to everyone to participate in. Even during the period where the study was live, small improvements were made to further increase the accessibility and usability of the website. As part of the recruitment of participants, an email about the project was sent to the WebAIM and WAI mailing lists to encourage participation in the study. A reply came back from the WAI list, explaining that the lack of focus styles on the website had been problematic for an individual. Following the receipt of this email, the focus styles employed on the website were improved, displaying outlines around any interactive elements on screen when interacted with.

4.5 Method #

This study investigates whether, when tasked with designing their own user interface, there are features of a user-interface design that, when personalised, will allow for the design to better meet the participant's access needs. In order to identify these elements, analysis of the results should indicate whether there are preferred options or patterns. If there are no preferred options or patterns for a specific element, as this thesis has covered, we can suggest that this will be due to the unique needs of individuals given their context, health and disability. As such, these elements could be identified as candidates for personalisation.

4.5.1 Participants #

All participants for this study were recruited through social media posts that were shared by those involved in this project as well as prominent Twitter accounts relating to website accessibility such as The A11Y Project (@A11yProject) and Accessibility London (@A11yLondon). 174 responses were recorded as part of this study, between 12th August 2020 and the 12th September 2020. Out of those 174 participants, 99 completed the Google Forms survey providing further contextual information: 56 identifying as male, 41 as female, 1 as non-binary and 1 participant preferring not to say. Ages ranged from 18 to 70+ years (the mode was 30-39 years). 14 participants identified as having a disability, such as chronic fatigue, or a visual impairment. A full list of the participants’ disabilities and access needs can be found in the Appendix, section 7.10. As the website was shared online through social media, participants came from a number of countries, the majority residing in the United Kingdom, but also included Australia, Benin, Cyprus, India and Nigeria to name a few. Apart from the first 3 participants who helped in accessibility testing the website who each received a £20 Amazon voucher, the other participants took part and were entered into a prize draw to win 1 of 5 £20 Amazon vouchers. On the first page of the website, the purpose of the study and the project’s background were explained to participants.

4.5.2 Materials #

As the study was shared online and participants were asked to independently create their personalised designs, various devices were used: 56 participants used a desktop computer, 32 used a mobile device, 6 used a tablet and 5 used a laptop. As participants were using the website independently within their own homes during the COVID-19 lockdown, there could have been a number of external stimuli affecting their participation but these are unknown.

The website for the Bog Roll Business Builder consisted of 9 multi-choice questions (Appendix, section 7.8), asking participants to choose their preferred option which would then contribute to the design of the toilet roll website’s user-interface that they were creating. The questions all related to aspects of the design that when personalised, may improve the accessibility of the design, as outlined in GOV.UK’s Dos and don’ts on designing for accessibility (Pun, 2016). An example of such a question would be:

How big should the font on your e-commerce site be?
Ensure that you can easily read it!

• Small
• Medium
• Large
• Larger
• I’m not fussed (Selecting this option would randomly select an answer from those listed above)

Following the completion of these 9 questions, participants were then asked to complete a Google Form that captured demographic information about the participant (Appendix, section 7.9) and qualitative contextual data about their Bog roll business builder designs. As participants were able to exit once they had completed their user-interface design, participants were encouraged to create their own personalised design with messaging that explained they would only be entered into the Amazon voucher prize draw following completion of the Google Form.

4.5.3 Design #

The study included 9 categorical questions, which were answered by all participants. For later analysis, participants were grouped as those that identified as having a disability (14 participants), and those who did not, or did not provide further contextual information through the Google Form (174 participants).

4.5.4 Procedure #

Participants completed the study by answering the 9 user interface design questions and then completing the integrated Google Form questionnaire, capturing contextual information.

4.6 Results #

To provide an overview as to the frequency of options selected and to allow for a comparison between the two groups (all participants and participants that identified as having a disability), histograms were created. Chi-square goodness-of-fit tests were then performed on all 9 decisions to determine whether an equal number of participants chose each option. There were significant main effects for all 9 personalisation features. Where significant main effects were identified across the whole sample of participants, that indicates that the participants were not randomly selecting options and were indicating a preference. As a result, these significant main effects were followed up with post-hoc pairwise comparisons with Bonferroni adjusted alpha levels for each feature.

To identify whether the participants who identified as disabled had the same preferences as the wider sample, the analysis procedure was repeated using the subset of 14 participants who identified as disabled only. Again, significant main effects were followed by post-hoc pairwise comparisons.

4.6.1 Text size #

The first option the participants could choose from specified the text size. Histograms 1 and 2 show the distributions of responses for all participants and the subset of participants who identified as having a disability, respectively. The mode for Histogram 1 was the Medium text size (n = 75), with Large text size also being favoured, (n = 65). Histogram 2 shows a similar distribution, however for participants that identified as having a disability, the mode was the Large text size (n = 6), with Medium the second most frequently selected option (n = 4).

The Chi-square goodness-of-fit test was employed for the whole sample, which returned that there was a significant effect for the text option (χ2 = 82.345, df = 3, p = <0.0005). As such, this was followed up with post-hoc pairwise comparisons using a Bonferroni adjusted alpha level, described below.

For the subset of disabled participants, the Chi-square goodness-of-fit test did not return a statistically significant effect for the text option (χ2 = 3.714, df = 3, n.s.)

4.6.2 Additional product information #

The second option asked participants the format as to which they would want to see additional information displayed. Histograms 3 and 4 show the distributions of responses for all participants and the subset of participants who identified as having a disability, respectively. Visual inspection of Histogram 3 (describing all participants) and Histogram 4 (describing participants that identified as having a disability) indicates that they have similar shapes. The mode for both histograms is the option that displays a mix of text and bullet points (Histogram 3, n = 81; Histogram 4, n = 7). Interestingly, none of the participants chose the option that displayed additional information with only text (n = 0).

The Chi-square goodness-of-fit test was employed for the whole sample, which returned that there was a significant effect for the additional product information option (χ2 = 78.520, df = 3, p = <0.0005). As such, this was followed up with post-hoc pairwise comparisons with a Bonferroni adjusted alpha level, described below.

For the subset of disabled participants, the Chi-square goodness-of-fit test did not return a statistically significant effect for the additional product information option (χ2 = 1.857, df = 2, n.s.).

4.6.3 Product options #

Participants then chose how they wanted product options, specifically sizes of the product, to be displayed. Histograms 5 and 6 show the distributions of responses for all participants and the subset of participants who identified as having a disability, respectively. Between Histogram 5 (describing all participants) and Histogram 6 (describing participants that identified as having a disability), the visual shape of the histograms are similar, the key difference being that in Histogram 2, none of the participants that identified as having a disability selected the option that displayed the product options inside a semantic HTML 5 select element (n = 0). The mode for both histograms was the option that displayed the options as a list of card elements (Histogram 5, n = 80; Histogram 6, n = 8).

The Chi-square goodness-of-fit test was employed for the whole sample, which returned that there was a significant effect for the product options (χ2 = 49.059, df = 3, p = <0.0005). As such, this was followed up with post-hoc pairwise comparisons with a Bonferroni adjusted alpha level, described below.

For the subset of disabled participants, the Chi-square goodness-of-fit test did not return a statistically significant effect for the product options option (χ2 = 4.000, df = 2, n.s.).

4.6.4 Image position #

For the fourth question, participants selected the visual position of the product image. Histograms 7 and 8 show the distributions of responses for all participants and the subset of participants who identified as having a disability, respectively. The mode for Histogram 6 was the option that displayed the image at the top of the design (n = 81). Histogram 7 visually shows a different distribution, although the mode was the same option, with the image being positioned at the top (n = 7).

The Chi-square goodness-of-fit test was employed for the whole sample, which returned that there was a significant effect for the image position option (χ2 = 63.784, df = 3, p = <0.0005). As such, this was followed up with post-hoc pairwise comparisons with a Bonferroni adjusted alpha level, described below.

For the subset of disabled participants, the Chi-square goodness-of-fit test did not return a statistically significant effect for the image position option (χ2 = 5.429, df = 3, n.s.).

4.6.5 ‘Buy’ button position #

Next, participants selected the position of the ‘Buy’ button within the design’s content. Histograms 9 and 10 show the distributions of responses for all participants and the subset of participants who identified as having a disability, respectively. The mode for both Histogram 9 and Histogram 10 was overwhelmingly the option that displayed the buttons towards the bottom of the content (Histogram 9, n = 131; Histogram 10, n = 13).

The Chi-square goodness-of-fit test was employed for the whole sample, which returned that there was a significant effect for the ‘Buy’ button position option (χ2 = 144.421, df = 2, p = <0.0005). As such, this was followed up with post-hoc pairwise comparisons with a Bonferroni adjusted alpha level, described below.

For the subset of disabled participants, the Chi-square goodness-of-fit test also returned a statistically significant effect for the ‘Buy’ button position option (χ2 = 10.286, df = 1, p = 0.001). Post-hoc pairwise comparison was employed to analyse this.

4.6.6 Colour scheme #

By this question, the majority of content would be on screen, as a result participants were then asked to pick a colour scheme for the design. Histograms 11 and 12 show the distributions of responses for all participants and the subset of participants who identified as having a disability, respectively. The mode for Histogram 11 was the option that presented the design in a light colour theme (n = 92). Histogram 12 shows visually quite a different distribution, both the dark colour theme and high contrast theme were the mode (n = 5).

The Chi-square goodness-of-fit test was employed for the whole sample, which returned that there was a significant effect for the colour scheme option (χ2 = 92.169, df = 3, p = <0.0005). As such, this was followed up with post-hoc pairwise comparison with a Bonferroni adjusted alpha level, described below.

For the subset of disabled participants, the Chi-square goodness-of-fit test did not return a statistically significant effect for colour scheme option (χ2 = 3.143, df = 3, n.s.).

4.6.7 Display of reviews #

Participants were then asked to pick a method for displaying reviews. Histograms 13 and 14 show the distributions of responses for all participants and the subset of participants who identified as having a disability, respectively. The mode for Histogram 13 was the option that presented the reviews in a concise, visual indicator (n = 79). Following a visual inspection, Histogram 14 shows a different distribution with the mean being different, for those that identified as having a disability, the mode was the option that displayed the reviews as quotes (n = 5).

The Chi-square goodness-of-fit test was employed for the whole sample, which returned that there was a significant effect for the display of reviews option (χ2 = 62.047, df = 3, p = <0.0005). As such, this was followed up with post-hoc pairwise comparisons with a Bonferroni adjusted alpha level, described below.

For the subset of disabled participants, the Chi-square goodness-of-fit test did not return a statistically significant effect for the display of reviews option (χ2 = 2.571, df = 3, n.s.).

4.6.8 Spacing size #

Penultimately, with the design almost complete, participants were tasked with selecting a spacing size for their design. Histograms 15 and 16 show the distributions of responses for all participants and the subset of participants who identified as having a disability, respectively. The mode for both histograms was the option that presented the design with medium spacing between elements (Histogram 15, n = 106; Histogram 16, n = 6).

The Chi-square goodness-of-fit test was employed for the whole sample, which returned that there was a significant effect for the spacing size option (χ2 = 136.757, df = 3, p = <0.0005). As such, this was followed up with post-hoc pairwise comparisons with a Bonferroni adjusted alpha level, described below.

For the subset of disabled participants, the Chi-square goodness-of-fit test did not return a statistically significant effect for the spacing size option (χ2 = 4.857, df = 3, n.s.).

4.6.9 Additional information #

To finish, options to display additional information were displayed to the participant in order to understand if individuals would prefer more useful information or whether they would select a Dark UX pattern that they may be familiar with. Histograms 17 and 18 show the distributions of responses for all participants and the subset of participants who identified as having a disability, respectively. The mode for both histograms was the option that presented the design with additional information about the purchasing process (Histogram 17, n = 115; Histogram 18, n = 10).

The Chi-square goodness-of-fit test was employed for the whole sample, which returned that there was a significant effect for the additional information option (χ2 = 110.111, df = 3, p = <0.0005). As such, this was followed up with post-hoc pairwise comparison with a Bonferroni adjusted alpha level, described below.

For the subset of disabled participants, the Chi-square goodness-of-fit test also returned a statistically significant effect for the additional information option (χ2 = 9.571, df = 2, p = 0.008). Post-hoc pairwise comparison was employed to analyse this.

4.7 Comparative Analysis #

Table 12 shows a comparison of the main effect outcomes for all personalisation features:

For 2 of the 9 features (the ‘Buy’ button position and the additional information) the disabled participants analysis and whole sample analysis were both significant. But for the text size, additional product information, product options, image position, colour scheme, display of reviews and spacing size features the effect for the whole sample was significant but not for the disabled participants

4.8 Feedback #

In addition to capturing contextual information from participants (such as gender, geographical location and whether the participant identified as having a disability) with the Google Form, participants were also asked to describe the reasoning behind the decisions that they made when choosing the options that led to their final design.

4.8.1 Key feedback #

In response to being asked why the participant chose the options they did, 45 out of the 99 participants mentioned their choices being based around which options provided them with a design that was easy to read or enhanced clarity and spacing of the design. Participants appeared to have a clear understanding of what they did and did not like based on their experiences with other e-commerce websites, some participants even citing ‘It's similar to many other online shops so everyone knows how to use it’. This follows Jakob's Law, the idea that users spend most of their time on other sites so if a site works similarly to their existing mental model, they will find it easier to use (Nielsen and Tahir, 2001). An alternative take came from a participant who had a clear idea of their preferences, formulated from their experience with e-commerce sites. They explained that in general they find e-commerce sites are ‘overly cluttered website[s] which are hard to read’. They also protested against ‘websites which are too pushy to sell, for example, viewing counters and sold counters are just distracting’, showing that they recognise these as Dark UX patterns and have formulated an opinion as to how sites should be structured. Out of the 82 participants who provided further information (rather than those who answered yes, no or NA), 41 participants mentioned that their design was easy to read, clear and quick for them to pick out key information and because of this, the design that they had created met their own personal needs. Interestingly, out of the 99 responses, 90 participants (roughly 91%) agreed that their personalised design met their own needs. This is reinforced by the comments left by participants, one pertinent example from a participant who commented, ‘it's straightforward and not too cluttered. I might even be able to read it without my spec[tacle]s’. This provides detail around a need that the individual has, i.e. they normally need glasses to read information. They propose that they may have been able to read the information within the design that they had created without their glasses, which may be handy within different contexts for example if they had forgotten their glasses, or may be in a situation where they cannot wear glasses.

4.9 Conclusion #

Before conducting the study, I hypothesised:

This study investigates whether, when tasked with designing their own user interface, there are features of a user-interface design that, when personalised, will allow for the design to better meet the participant's access needs. In order to identify these elements, analysis of the results should indicate whether there are preferred options or patterns. If there are no preferred options or patterns for a specific element, as this thesis has covered, we can suggest that this will be due to the unique needs of individuals given their context, health and disability. As such, these elements could be identified as candidates for personalisation.

To summarise, table 12 shows the comparison of analysis between the whole sample and disabled participants subset. The whole sample returns a significant result for every personalisation feature, yet for the disabled participants, only 2 of the features are significant. Looking at the inferential analysis of significant results for independent personalisation features across the whole sample, a pattern emerges. This pattern tends to consist of there being 2 options that are selected much more frequently than others. These options tend to be fairly similar, a good example of this would be for the text size selected. The most frequently selected options across the whole sample were medium and large. Only 14.4% of participants selected small or extra large, the rest all selecting medium or large.

The results of the chi-square tests challenge the original hypothesis. For the whole sample, as previously stated, for every feature that the participant was asked to personalise, there was a significant result. This means that the spread of answers was not random, there were answers selected more frequently than others by the participants. From this, we can infer that for the majority of participants, as they do not identify as having a disability, that they are accustomed to certain aspects of web design and as a result, tend to all recognise common patterns and would include them in their own designs. However, given that for the disabled participants there were only two significant personalisation features, it stands that there may be a wider range of needs that were being addressed by the different design options. As 7 out of 9 of the personalisation features did not identify significance, the frequency of selected answers resembled more of a random spread. This random spread and the choice of answers illustrates a wider range of accessibility needs from disabled participants, whose needs may differ greatly depending on their disability and health.

4.9.1 Areas for improvement #

Despite the positive implications of the findings, the study could be improved in a number of areas in order to provide a more in-depth analysis of the needs of individuals with disabilities. In order to improve upon this, a much larger sample size, including a wide variety of different disabilities, users with combinations of disabilities, users of assistive technology across a range of different technological skill levels would be needed. This is a problem that needs addressing as the current study captured the thoughts of 14 participants with disabilities, but is nowhere near a big enough sample size to understand the needs of people with all those different factors taken into account. Another aspect of the design of the study that would need to be improved upon if conducted again, would be to exact further control over the stimuli and devices used to conduct the study, as to make the study more controlled and repeatable. Another aspect of the study that could be changed, would be to limit the device types that a participant can use. However, if device types are limited, certain users may feel uncomfortable being constrained to devices that they are not familiar with, which may affect the results as well.

4.9.2 Future areas of research #

Based on these findings and the areas for improvement, it is possible to suggest foci for future research that would help to build upon the understanding of personalisation and who it benefits. One of these future research focuses should be to understand if the need for personalisation changes depending on different types, degrees and combinations of disability. As hypothesised earlier, personalisation of user-interfaces may be particularly useful to individuals with different combinations of disability as their needs may differ radically to the needs of an individual with a single disability. As WCAG are developed for groups of disabilities, the individual and complexity of combinations and varying degrees cannot be accounted for. A focus here, would evidence a real benefit of personalisation.

In addition to this focus, to reiterate the point made at the end of the improvements section, developing a study with more controlled stimuli across different contexts would also provide really useful insight as to how needs change depending on context, for all users. Asking a participant to use the website once within the comfort of their own home, but then again while walking to the shops, may provide a really interesting insight as to the features of a user-interface that are the most important to us, given the different contexts of use.

4.9.3 Summary #

To conclude, this study has provided an understanding that the personalisation of user-interfaces can provide benefit to disabled users of websites. For the majority of an interface’s features, disabled users may want to personalise the design in different ways to meet their differing accessibility needs or goals. In contrast, analysing the results across the whole sample provided a different perspective, in that most users who did not identify as having a disability tended to focus around, typically 2, specific answers - their answers were not spread in the way that disabled participants' answers were. From this, we can infer that personalisation may be particularly useful to disabled users of websites, while still being of some use to those that do not identify as disabled.

Pairing this statistical data with the contextual information that participants provided in the Google Form, it provides an understanding that users are able to successfully personalise the design of a website and in doing so, they are able to consider their own needs and meet these successfully.

5 - Study 2: Miss Thread #

5.1 Introduction #

A 'Norman' door is the name given to doors that confuse the user as to whether they should be pushed or pulled, due to nothing correctly signifying the interaction (Norman, 2013, 1-3). For example, a door that has a handle facing you would lead you to believe that this needs to be pulled towards you. However, if this door then said the word 'Push' above the handle, the text contradicts the interaction afforded by the use of a handle to pull on. This would be an example of a 'Norman' door. The term was coined by Donald Norman who further explores this concept and the importance of affordances, explaining how interactions can be signified, for example, on a pull door with the use of a pull handle. Affordances are used in web design to highlight interactions to the user. Without affordances on websites, visually and semantically, it would be extremely difficult to understand the possible interactions.

Therefore, users of a website that may be personalised need to understand that a website is able to be personalised. In order to do this, there needs to be affordances signifying this possibility. In the previous study, Study 1 - Bog roll business builder, the affordances to personalise the design were clear. The design to be personalised sat next to the questions which, step-by-step, allowed the participant to personalise their design. The user did not have to go looking around to understand that the design could be personalised, it happened by them answering the questions in the survey. However, for any given traditional e-commerce website, the main aim is to sell products, not to allow a user to personalise the design. Due to this, affordances need to be designed, developed and tested, so that the content on an e-commerce page is unaffected, but signifies and allows the user to change the design to meet their needs. This is the problem area that this study will address. Additionally, this study will seek to understand if personalisation can be implemented in a way that would be reusable by other developers, without dramatically increasing their workloads.

In order to focus and get individual feedback from users, the approach taken towards this study was to develop an interactive prototype for a specific type of e-commerce website that could be used and tested during usability tests and developer interviews to receive qualitative feedback. In addition to this, the format of the study meant that the entirety of the interviews could be conducted online and that users of assistive technology would be able to use their own devices that they typically use when browsing the Internet. Because of this, the site was designed using features that would work within any modern browser. Ethical approval for the project was obtained through the University of York - Theatre, Film, Television and Interactive Media’s ethics process and adhered to throughout this study.

5.2 Inspiration #

Looking back at the previously mentioned e-commerce examples, a particular industry stands out, the fashion industry. For an industry that bases itself on self-expression and the idea of allowing the individual the freedom to represent themselves as they see fit, there is an irony in the fact that out of 30 e-commerce websites, only the ASOS (fashion retailer) website conformed to the minimum level of WCAG (Sohaib and Kang, 2016, 466-475). However, fashion has additional problems outside of its online presence such as a lack of diversity, with discrimination and lack of racial diversity (Elan, 2019) (Reddy-Best et al., 2017) as well as an inability to fairly represent different bodies in terms of shapes, sizes and disabilities. In a way, fashion represents the problems apparent within website design. Products are developed quickly for a group of users, without the needs of individuals with their differing needs being considered. As such, the end product meets the needs of non-disabled people, but is rendered useless by everyone else who cannot use the product. The recent rise of fast fashion and influencer trends contribute to increased poverty (Brooks, 2015), human trafficking (Aronowitz, 2009) and the climate crisis (Davis, 2020). In addition to these problems, fast fashion retailers such as Fashion Nova, Google’s most searched for fashion brand in 2018 (Google Inc., 2018), have recently adopted accessibility widgets or panels. The idea with these widgets and panels is that they can be dropped into an existing site and using some form of machine learning or artificial intelligence, they can make a site fully WCAG 2.1 AA compliant. These are the claims of the Accessibe’s accessibility panel developers, the tool that can be found in use on Fashion Nova’s website. Accessibe have gained a form of notoriety in the web accessibility community for being almost the opposite of what they promise. Roselli (2020) went as far as writing a post titled ‘#accessiBe will get you sued’, documenting issues that span from an inaccessible product to producing ableist content and paying for praise.

In order to accurately design a study that would reflect the e-commerce fashion websites that are popular within the UK, the 10 highest ranking websites (when searching for ‘Women's fashion’ on Google in August 2020) were analysed. These websites can be found in the Appendix, section 7.11.

5.3 Designing the prototype website #

For each of the 10 fashion websites, screenshots were taken of the website's home page as well as an individual product’s page, representative of the layout for all product pages. The screenshots were then placed into a graphics editing software, where the content was used to create a basic wireframe structure.

Once wireframes had been created and the information architecture had been analysed, it became possible to understand patterns within the structure and content of the e-commerce sites. The wireframes were blocked out into sections illustrated by colour, this was done so that all 10 sites could be combined, by reducing the opacity of each individual wireframe and then merging them all together, producing a content heat map. This helped the design of this study as, combined, the wireframes created an archetypal visual template, guiding the design and clearly illustrating the structure and layout of the content. The name ‘Miss Thread’ was given to the prototype as the word ‘Miss’ appeared in 3 out of the 10 sites analysed and ‘thread’ being a colloquial, informal term for clothes. Graphics featuring in the site were obtained from royalty free image sites by searching for terms such as ‘fashion’, ‘clothing’ and ‘model’.

5.4 Structuring the prototype #

Based on research conducted as part of the literature review, Stuerzlinger et al. (2008) provided criteria for adaptable user interfaces. The criteria included fast, simple, just-in-time customisations as well as global and local customisations. In order to meet this criteria, the prototype was designed to be able to be personalised globally (across the site), as well as on individual elements. In order to achieve this, the design of the site is implemented in a way so that key values for the features that are personalised can be abstracted from the code and thus updated easily. For example, the value given to the line-height property is abstracted into a CSS Custom Property (which could be a design token) so that it can be easily changed with personalisation. The structure of the CSS itself follows the CUBE CSS methodology specified by Bell (2020). This methodology allows styles to cascade, meaning that values of properties are inherited and propagate throughout the design of the site. This is ideal for personalisation and works particularly well, as opposed to other CSS properties such as Block Element Modifier (BEM) (Roberts, 2013), where the scope of properties is carefully managed with low specificity selectors.

For the user, there are different areas where they can make these personalisations. The first area is a page that can be accessed from the footer of each page. This page provides the user with some example content typical of the site, such as products and an advert. A full list of the global personalisation options can be found as part of the Appendix, section 7.12. Selecting an option will update the global design of the site instantly, so that the user will be able to understand what the personalisation option does. To aid this, the sample content on this page provides a way for users to further understand the effects and understand if the design meets their needs. The options are displayed using HTML5 elements to ensure accessibility with assistive technology. For the local personalisation options, when a user visits a product page on the website, hovering over elements on a page or tabbing through the page with a keyboard will reveal an element titled, 'Change this styling'. Selecting the element will reveal a list of options that can be used to personalise the individual element. A full list of the local personalisation options can be found as part of the Appendix, section 7.13. Selecting an option will update the design of the specific item instantly as well, replicating the way that the global personalisations work. Local personalisations can be made in any order, there is no pattern that a user has to follow in order to personalise the individual items and the ability to select the 'Reset styling' option within the dropdown provides the user an easy way to remove those local personalisations. The dropdown is displayed using the HTML5 details and summary elements and as with the global personalisation, the options are displayed with HTML5 form elements to ensure accessibility with assistive technology.

5.5 Disabled participants feedback on the prototype #

5.5.1 Testing the prototype with disabled participants #

The plan was to conduct accessibility testing of the prototype website with 3 disabled users that use assistive technology. As part of the recruitment, 5 disabled participants that had completed the Bog Roll Business Builder study and had indicated they were happy to take part in further research, were initially contacted. At the same time, messages were sent to disabled Twitter users that were prominent within the field of website accessibility on Twitter. As a final attempt to recruit participants, The York Disability Rights Forum offered the opportunity to promote the research on social media and within their newsletter, for which I wrote a short blog post on their website to promote the recruitment of participants. Despite these efforts, only 1 participant was recruited to test the accessibility of the prototype website that had been developed.

For the study, the participant was asked to complete a series of tasks, which were to:

• Find a specific item of clothing on the website
• Find the price, size and height of the model on the item's specific page
• Select a size and add the item to the user's basket
• Navigate to the basket and review the order

These tasks were developed as part of the problems identified from The Click-Away Pound Report, but also adapted as part of the testing conducted by Gonçalves et al. (2017), in which they evaluated the accessibility of e-commerce websites with blind users. The participant was asked to complete the set of tasks first, without any personalisations made to the site and once complete, to go through the tasks again, this time making global personalisations beforehand, where relevant and to then make local personalisation during the tasks where relevant.

5.5.2 Working towards a theory: Accessible, personalised designs #

The participant is a user of the NVDA screen reader and was able to complete the study very quickly. While the participant has experience with web accessibility and the WCAG, this is through advocacy work, explaining their own experience and advocating for a better experience for all. The planned time for the tasks was about 40 minutes. This was to allow and account for problems with the design of the site and potential accessibility issues. However, the participant completed both sets of tasks in 11 minutes and 5 seconds. When asked if there was a version of the website that the participant preferred, they explained that they had no issue with either version of the website (the default design and their own personalised design), as both designs were accessible with WCAG 2.1 AA (as illustrated in the literature review section 2.1.2 - Accessibility in the context of e-commerce, this is uncommon within fashion retailer websites). The participant went on to explain that they liked having the ability to personalise the information and specific elements (local personalisation) on the product pages. They specifically mentioned that the ability to switch between bullet points and paragraphs of text was useful. As this participant is blind, they explained that the options that affect the visual styling of the page were of no use to them, but the functionality that changed the content that was on the page was useful. The screen reader software has no way of synthesising extra information beyond what is on the page, so to allow for this information to become available was useful.

One of the questions following the tasks asked whether the participant would spend the time and effort to personalise a website's design if they had not been asked to do so. They explained that they would want to see the options that they were able to personalise, out of personal interest and to see if there was anything that would be of use to anyone. The participant also explained that while they thought the personalisation options were relevant, they were unsure if they were that relevant to their own needs. Personalisation options such as additional skip links were not used by this user as they already use keyboard shortcuts to identify all of the headings on the page and then navigate through these headings. The personalisation feature that displays a summary of the page's content was interesting in places to the user, however, they suggested that it was too far down the content of the page to be of use to them and suggested it be moved just below the existing skip links, so that they may be more relevant. The participant theorised that for screenreader users, personalisation might be pertinent for those that are new to the technology or who have just developed a visual impairment, their reasoning being that screen reader technology can be difficult to initially understand and using personalisation to help a user navigate and understand content, may help these users initially. This feedback pertains to the idea for personalisation of user interfaces developed during the literature review, the idea that people are not static in their needs and abilities (Gregor & Newell, 2001) and while the writing earlier (section 2.1.3) focused on how abilities can deteriorate with age or during certain contexts of use, it did not consider that for some, the ability to use technology or skill in using certain software may be completely new to an individual.

Finally, regarding the affordances and identification of controls to personalise the design, the participant completed this with relative ease. Following the tasks, the participant commented on how they thought the positioning of the dropdown menus for the local personalisations was really effective. They explained that when navigating through the content on the page, the dropdown menus were in a good position, so that they were reachable straight after the item they related to. One aspect of the design that the participant thought did not work well was the positioning of the link to access the global personalisations. The participant explained that the links were not where they would have expected to find them at all, this was in part due to the fact that during development, these links were not wrapped in a semantic HTML 5 navigation element, which would have helped to identify these links.

5.6 Developer feedback on the prototype #

5.6.1 Understanding the developers' needs #

To understand the amount of development effort that would be required in order to adopt this method of personalisation that had been prototyped, 3 participants were recruited. The roles of these participants were:

• EFWD - Educator and Freelance Web Developer
• UIDL - User Interface Design Lead
• DPDM - Digital Projects Design Manager

The participants recruited were those that also participated in the initial developer interviews, section 3.3. Participants were shown a 5 minute, pre-recorded video (Appendix, section 7.14) that demonstrated the use of the system with global and local personalisations, the structure of the CSS, the way that personalisations were stored and the functionality working within the prototype website. They were then asked 6 non-technical questions relating to their thoughts on what they had seen and their opinions as to how the prototype could be adapted to work in systems that they were familiar with. A complete list of the questions asked can be found in the Appendix, section 7.15. Following the transcription of the interviews, they were imported into Taguette (Rampin, 2020), a note tagging piece of software used for tagging text and creating taxonomies. The software runs locally on a machine, meaning that none of the information is ever sent to a server and as such, the software can work completely offline. To code the data, a deductive approach was used, with a set of predefined codes relating directly to the questions that were being asked. These codes can be found within the appendix, section 7.16.

5.6.2 Working towards a theory: A revised development method with personalisation #

First, participants were asked, given the way that the prototype works as well as the constraints of their current systems, how easy of a task would it be to implement personalisation as demonstrated by the prototype. All 3 of the participants explained that they thought personalisation could be adapted with relative ease, ‘I think it would be quite easy to adopt, absolutely’ (UIDL), ‘I could see that being something that we already do... it's just, yeah... it's like an extra thing on top of that’ (DPDM). DPDM explained that as they already develop styles that respond to different devices with the use of CSS Media Queries, that personalisation would not require that much additional work and that in a way, they were already making similar changes. The other participants came at this from a different angle and explained that they could foresee the method of personalisation that had been developed being easy to include, depending on how straight forward it would be to abstract key values from existing CSS files. If there were common values used throughout styling sheets already, or if there were pre-processing tools that were inputting variables, then it would be a relatively straightforward and simple task to complete.

To ensure that personalisation would not affect branding and marketing guidelines of the brands that adopted personalisation, all of the participants individually suggested that the variations of designs should be created collaboratively with internal branding and marketing teams. They believed that doing so would allow for personalisation that does not cause any friction internally, but provides the user with the ability to make the site more usable given their access needs. As long as the branding/marketing teams understand that personalisation is not to be used as a tool to aesthetically change the design of the site, but to increase the usability, this should not be a problem that blocks adoption. DPDM went as far as thinking of potential issues that branding teams would have with personalisation, such as ‘that's not our colours’ and rebutted the concern by explaining that such issues could be overcome by explaining both the usability and business issues. In response to personalisation producing different colour schemes, DPDM suggested explaining that people with visual impairments may not see colours in the same way before any personalisation had taken place and that if changing the colours meant that they were able to then use the website and complete their business, that the argument would not hold.

Participants were slightly unsure as to how their testing workloads would increase as a result of adopting personalisation. However, as they spoke, they began to develop methods that would mean that testing would not need to increase that much. One participant suggested that personalisation may increase the need for testing to be done upfront, before putting products together, whereas another participant suggested that as long as the controls for personalisation was obvious, there would not be the need for much more testing. Combining these answers produces more of an encompassing overview of the workload that would be needed to test personalisation. In order to test the usability and accessibility of the personalised elements, the participants’ answers combined suggest that testing would need three stages. The goals of each stage of testing would be:

1. Ensure that each personalisation option meets WCAG
2. Automated testing to ensure that combinations of personalisations do not break the layout or design of the website
3. Usability and accessibility testing to ensure that users can understand how to make the personalisations and also to ensure that they can be removed.

Starting with tests to ensure that each personalisation option meets WCAG is the simplest. UIDL suggested designing the different options in isolation from other styling. To put this into context, instead of looking at everything on a page, you would abstract an element from the design, such as line height. Together with the branding and marketing teams, you could then agree on a range of line heights that would meet the WCAG. Once you have your design tokens that meet WCAG, you could then include these in your design system. When this is complete, you could make use of automated testing tools, such as those described by DPDM to ‘automatically test that kind of thing, take all of your screenshots and compare them’. Very quickly, you could use existing frameworks and libraries to produce automated tests that can provide you with screenshots for all of the different combinations of personalisation options applied. Using a method of visual regression testing, you could compare the screenshots and visually ensure that there would not be any breaking styles applied to the design of the site as a result of personalisation options employed. The final stage would then be to test with users. Following the investigation into the definition of accessibility, section 3.5.1: automated testing is used to pick up easy to spot, minor issues but requires that testing is conducted with real users, with a range of access needs. This testing would be used to make sure that individuals could understand the options presented to them, make the changes themselves and then revert the changes and get back to the original design and styling if needed.

5.7 Conclusion #

This study has illustrated a possible method that allows for the personalisation of a user interface by an individual, without dramatically increasing a developer's work load. A screen reader user was able to quickly and successfully personalise a typical fashion e-commerce website's design to better meet their needs. Following interviews with 3 participants that hold different roles in website design and development, their shared opinions provided a view that it may be possible to adopt these methods of personalisation without a large increase in workload.

5.7.1 Limitations of the study #

Considering the work completed for this study, there is a key area for improvement, which is to further the testing of the prototype with individuals with a range of different access needs. As the prototype was only tested with a single participant, it is difficult to abstract common themes that would be the same for all users. For example, the participant that tested the prototype was able to easily identify how to personalise the website, but there is no certainty that all NVDA screen readers would be able to do the same. There would need to be testing with a much larger sample of users with different combinations and disabilities in order to actually understand the effects of personalisation and to analyse if it is helpful to the majority of individuals with their own unique access needs.

Looking towards the designer and developer interviews, this aspect of the work could also be improved by allowing the participants to have a go themselves at implementing personalisation as part of a demonstration. This way, they would be more informed as to how much of an effort implementing personalisation would be within their own systems. In addition, allowing developers to personalise the website themselves may have revealed considerations about different devices or contexts of use that they themselves are familiar with, which could have furthered the understanding of this research.

5.7.2 Future areas of research #

Given the large room for improvement, a key area for future research would be to conduct similar testing of the prototype but on a much larger scale. The idea would be to recruit participants that are much more representative of the disabilities that make up the UK's population, which would help to further inform the key functionality and features that would need to be implemented. Building on the work with the designer and developer interviews would also help to develop this study. A future area that would be interesting to explore, would be a collaborative development approach in which a designer or developer is tasked with implementing personalisation within an example site. They could work their way through designing the different personalisation options, implementing and testing it to give them a thorough idea as to the process. Conducting such an activity would also highlight friction points within the developers' experience and provide opportunities for iterating upon the method for implementation.

5.7.3 Summary #

This study has identified a way of allowing individuals to personalise a user interface to better meet their access needs in a way that affects elements on the site globally and locally. Despite not being tested by a large enough sample to produce results that are conclusive or transferrable, the study provides a foothold from which future research can develop from and build upon. In addition to the feedback from accessibility testing the affordances, the designers and developers interviewed provided a shared opinion that given the current technologies and the way that key values can be abstracted from designs, implementation may not dramatically increase the workload. Pairing personalised components with clear, principles based, design systems documentation would allow for reusable implementation that would benefit both users and developers who are not encouraged to consider the user's needs.
In order to realise the full potential of this research, this work would have to be iterated upon, focusing on the areas of improvement described in this conclusion.

6 - Conclusions #

Fundamentally, the primary aim of this research was to develop a method for making e-commerce websites more accessible to the individual’s needs. This research has provided an overview of the access barriers that can be found within e-commerce websites.
Statistics provide a bleak outlook as to how accessible the web is to all users: 97.8% of website homepages tested did not meet WCAG (WebAIM, 2019); the value of business lost by inaccessible websites in the UK in 2019 was £17.1 billion; out of 20 e-commerce websites tested, only one met the minimum level of WCAG conformance.

More than this, websites that conform to the WCAG may include accessibility issues that are not covered by the guidelines (Power et al., 2012). Consulting the guidelines, a statement within the introductory section explains that the guidelines do not ‘address the needs of people with all types, degrees, and combinations of disability’ (W3C, 2018). But as individuals, our access needs are not a static entity. Our needs are related to our health, to our contexts of use and the equipment that we use (Government Digital Service, 2019). As a result of these failings, individuals are discriminated against due to their differing access needs. Kalbag (2017) contextualises this issue:

Individuals may also have more than one impairment, which alone don’t cause much difficulty, but together can create a more significant disability. For example, age may cause your eyesight to deteriorate, forcing you to enlarge screen text size, while arthritis might leave you with impaired coordination, making a mouse awkward to use, particularly with accuracy and at speed. The combination would have quite an impact on your ability to use the Internet.

6.1 Reviewing research objectives #

The research questions laid out during the introduction of this research were as follows. This subsection will review how these questions have been answered and will discuss insights provided by the outcomes of this work.

Research question 1. What are the accessibility problems encountered on popular e-commerce websites in the UK?

Research question 2. Would allowing users to personalise an e-commerce website's user interface cause users to perceive their personalised design as being more accessible that the standard design?

6.1.1 Research question 1 #

In relation to research question 1, this research has identified that there is a lack of guidance around developing websites that meet the needs of individuals (Lopes et al., 2010). Beyond this, there is a failure to adopt accessibility guidelines across all websites given the lack of website home pages that conform to the guidelines (WebAIM, 2019). Pairing this analysis with information from The Click Away Pound Report (Williams and Brownlow, 2020), we can identify that the most frequently encountered problems include 'crowded pages with too much content', 'poor link information and navigation', 'poor legibility' and 'distracting moving images and graphics'.

This research has identified that accessibility problems within e-commerce websites may be caused by two main issues: a lack of understanding or general definition as to what accessibility is, which is exacerbated by the prioritisation of business goals ahead of the needs of users. When interviewing designers, developers and accessibility consultants that work alongside those that implement user interfaces and designs, it became clear that between the participants, there was no single way that they defined accessibility. For some, accessibility was conforming to WCAG 2.1 AA level, yet for others it was ensuring that products could be used by disabled users with no issues. Participants commented on the difficulty to understand the Web Content Accessibility Guidelines, given the depth of the document and the way that tests can be open to interpretation. Alone, this problem may not be that problematic. However, as explained by participants during the interviews, their roles tend to exist in small teams at the centre of different businesses. Due to this, they produce guidelines and documentation for other teams conducting development and implementation to use. As explained by participants working in larger organisations, there are not accessibility or usability specialists in every team. As such, accessibility, and therefore usability is not always initially considered. This may be due to the way that businesses prioritise business goals over the needs of a user. The business' primary goal is to further grow and develop their products, not to necessarily help the user while doing so. The business wants to beat competitors to launch, in the hopes of attracting the most business. To put this into context, a participant explained that the goal of an e-commerce website would be to try to sell a user a mortgage or loan, regardless of whether it is in the user's best interests. As such, recruitment favours developers, so that products can be developed faster, with increased functionality. This has led to the rise of frameworks such as 'React' that favour the prioritisation of the developers' experience, offering no guidelines or practices for developing accessible, user friendly websites.

6.1.2 Research question 2 #

Turning to research question 2, through two different studies, this project has developed a method of allowing individuals to personalise the elements of an e-commerce website's user interface. In doing so, it has allowed individuals to be able to personalise the design of elements globally across a website, in addition to changing the design of specific elements on a page. The options that can be personalised relate to best practice recommended by the Government Digital Service (Pun, 2016) and design choices that attempt to address the most frequently encountered accessibility issues on e-commerce websites (Williams and Brownlow, 2020).

In order to develop this method of personalisation, two different studies were conducted. The first, with the goal to further understand the elements of user interface that could be personalised to better meet the user's access needs. To do this, an interactive website was developed that allowed individuals to create their own toilet roll selling e-commerce shop designs by selecting options from multiple choice questions. The study identified that personalisation may be of particular interest to disabled users as their answers tended to be more diverse and not focus on a specific option. When providing contextual information, 91% of participants agreed that the design that they had been able to independently create, met their own access needs. Participants provided feedback on their designs, explaining in detail how the designs met their needs:

... it's straightforward and not too cluttered. I might even be able to read it without my spec[tacle]s

The second study then adapted the personalisation options and integrated them within an example e-commerce website, providing affordances that could be tested with different users and a method for implementation that would not dramatically increase a developers' workload. The method of personalisation was tested by a single screen reader user who found the affordances for personalising the site accessible and easy to use and understand. In addition to this, web designers and developers were interviewed in order to understand their opinions regarding the adaptation and implementation of such a method within their own organisation and products. Feedback was positive and those interviewed explained that given the abstraction of key style values (such as font sizes, colours and line heights), implementation would not be difficult. The participants also provided clear views and arguments that could be used to win over other teams that may challenge the use of the functionality, such as branding and marketing teams as well as other stakeholders.

6.2 Limitations #

The strength of these findings are limited by the small number of participants with disabilities that took part in the studies. For the first study, there were fourteen disabled participants and for the second study, there was only a single participant. As the World Health Organisation (2020) explains:

Disabilities is an umbrella term, covering impairments, activity limitations, and participation restrictions.

As the term disability can include so many different impairments and as discussed earlier, people can have different combinations of disability and needs are always changing; it is hard to imagine that the fourteen participants' individual needs are representative of a population. Because of this, additional research would need to be conducted with a much larger group, representative and made up of people with disabilities that represent the UK's population in order to further understand how applicable personalisation is. In addition to this, being able to conduct another round of testing where disabled participants use the prototyped methods of personalisation in different contexts of use would also provide more insight as to how useful personalisation is and highlight areas for improvement.

6.3 Implications of this work #

Looking forward, toward the implications of this research and the scope for additional work, the outcomes from this project provide the foundation for future researchers to further investigate the effects caused by personalisation. This work has highlighted the possibility for websites to adapt personalisation and suggests feasible ways that e-commerce sites could accommodate this, as evidenced through the second study. Also, given that the use of design systems targeted for the web is relatively new, with the adoption of design tokens, personalisation could be included as part of the default process for creating such a system. This would further increase accessibility across the web. While the remit of this project has focused mainly around e-commerce websites and the practice and patterns that this industry follows, there are learnings that could be transferred across to different forms of interactive media. It is not farfetched to imagine the user interface of a video game that allows a player to personalise the layout of a user interface to better meet their needs. This can already be seen happening through the use of modifications made by players of the games Skyrim (Bethesda Game Studios, 2011-2018) and The Witcher 3 (CD Projekt Red, 2015-2019), where mods improve aspects of the game’s design including colour contrast (MGE, 2019) and the size of subtitles (CowKiller, 2017).

In contrast to the adaptive user interfaces designed by those working within a distinctly non-diverse industry (Tech Nation, 2018) (State of CSS, 2019) where more and more complex solutions are being designed that seek to tell users what their needs are, we should aim to provide individuals with more control. Automated solutions are leaning constantly further into colonial design and are not representative of the user’s needs and as such, they do not work (Roselli, 2020). This research has illustrated that it is possible to allow individuals to personalise the user interface without a vast amount of additional development, which can better meet the needs of individuals by a medium that, as evidenced throughout this thesis, has so far failed to do so.

7 - Appendix #

Table of contents #

• 7.1 - Developer interview questions
• 7.2 - Description for the Developer Interview codes
• 7.3 - Developer Interviews: DPDM Transcript
• 7.4 - Developer Interviews: UXRL Transcript
• 7.5 - Developer Interviews: AS Transcript
• 7.6 - Developer Interviews: UIDL Transcript
• 7.7 - Developer Interviews: EFWD Transcript
• 7.8 - Study 1: Bog Roll Business Builder interactive website questions
• 7.9 - Study 1: Google Form survey questions
• 7.10 - Study 1: Participants’ disabilities and access needs
• 7.11 - Study 2: Fast fashion websites analysed
• 7.12 - Study 2: Full list of Global personalisation options
• 7.13 - Study 2: Full list of Local personalisation options
• 7.14 - Study 2: Demonstration video shown to developers and transcript
• 7.15 - Study 2: Interview questions
• 7.16 - Study 2: Description for the codes
• 7.17 - Study 2: EFWD Transcript
• 7.18 - Study 2: UIDL Transcript
• 7.19 - Study 2: DPDM Transcript
• 7.20 - Developer Interviews - Email Consent Form
• 7.21 - Developer Interviews - In person interview Consent Form
• 7.22 - Developer Interviews - Video call interviews Consent Form
• 7.23 - Developer Interviews - Information sheet
• 7.24 - Study 1 - Participant consent information displayed on the front page of the website
• 7.25 - Study 1 - Participant information sheet
• 7.26 - Study 2 - Participant consent Google Form
• 7.27 - Study 2 - Participant information sheet
• 7.28 - The Bog Roll Business Builder Website

7.1 - Developer interview questions #

Developer interview questions were planned to try and learn as much information as possible in relation to these goals. The main questions asked in the interviews are below, with reasoning and how these should contribute to achieving the goals listed in the section.

1. What do you do in your day-to-day role? What are some of the main aspects?

The aim for this question was to get participants comfortable and to get them talking. meant to be introductory and easy to answer (Wilson, 2014, 35). This question acts as a way to gather more information about the participant's role and their day-to-day work.

2. What excites you most about (your/your teams) work?

Another introductory question, with the aim to understand aspects of the work that the participant enjoys.

4. What do you think are the most challenging aspects of designing user friendly, accessible interfaces? Why?

This question is directly linked to the second goal described earlier in this section. The wording of the question is purposely open-ended and the term challenging is not defined so that participants may think of all challenges that they face, regardless of the challenge's type. Asking about designing both user friendly and accessible interfaces, allows for the possibility of identifying larger issues with development that may not be directly linked to accessible development, but could hinder developed software being accessible.

4. When designing a new user interface component or feature, do you have a process for doing so?

A similar method is used for this question. By asking the participant about designing a new user interface component or feature, the question attempts to remove any thoughts of migrating old legacy code. Instead, it asks users if you were starting fresh and were planning to design something, how would you go about it? This question is designed to understand developer workflows and get an idea for the hurdles that a developer may face.

5. In regards to working on a user interface, how do you evaluate the success of a design?

While this question does not directly link to any of the goals of this section, nor the research questions, looking ahead to developing a personalisable interface it seems important to understand different definitions for success. In doing so, this could be taken into account and planned for later testing.

6. How do you ensure that the interfaces are accessible?

Up to this point, accessibility has not been mentioned. This is on purpose and to see if developers naturally relate their previous answers towards accessibility. The question avoids mentioning the WCAG or any legislation in the UK, this is again done to prevent putting words in participants' mouths and to see if there are any other metrics that those in industry use to check accessibility.

7. What do you see being the biggest opportunities or challenges for accessibility in the future of this field?

It is clear that this question relates to the final goal for these interviews, with the aim to understand future opportunities and challenges. As one of the last questions in the interviews, it will act as an opportunity to summarise the issues that the participant may have discussed. Looking forwards they may see these issues transform into opportunities and speculate as to other issues that may develop.

8. Is there anything I've missed?

Finally, this question will seek to catch any information that the participant deems relevant but has not had the opportunity to raise.

7.2 - Description for the Developer Interview codes #

Below are descriptions for the codes that were used when analysing the developer interviews.

Accessibility opportunities

• Accessibility opportunities are general suggestions for the improvement of accessibility, within interactive media, in the future.
• This will be recognised when people talk directly about future opportunities for accessibility. These opportunities may arise through discussion of working patterns, business goals or challenges when designing interactive media.
• The accessibility opportunities recognised must be opportunities that will enhance the adoption of accessible development or increased accessibility for all.
• An example of this would be a developer who has identified that they can use a certain technology to check accessibility requirements before beginning development.

Challenges when designing accessible content

• The ‘challenges when designing accessible content’ code can relate to any difficulties faced when designing accessible interactive media. These may include more personal issues, such as a failure to empathise with a disabled user's experiences, or may relate to external pressures, such as business' demands for faster development.
• This topic may be recognised when interviewees discuss their current working patterns or challenges for accessibility in the future. It could be any reason as to why the interviewee recognises that interactive media is not accessible and as a result may be something that they have experience first-hand or could be a process that they are aware of.
• This topic is the most general out of the planned coding topics as to allow for the interviewee's responses to guide themes around this topic.
• An example of this may be that an interviewee recalls an earlier project where they failed to consider accessibility during the design of an interactive piece as they struggled to understand the WCAG.

Measuring success

• Excerpts coded as having a 'Measuring success' theme are related to a process or testing method in place, used to evaluate if a design is successful.
• This topic will be identified when interviewees are directly asked about any measures that they have in place to identify success.
• This theme will not exclude any measures for success and instead, will seek to identify different measures used and understand if there is a consistent theme that can be used to measure the success of this project.
• An example of this may be a test that is in place following every AGILE sprint at a company to ensure that screen reader users can successfully use the newly developed product.

Role

• Role relates to the day-to-day job of the individual being interviewed. It should explain the work they do in relation to designing and developing interactive media.
• It should be recognised within the answer of the first question during the interview, when the participant talks about their day-to-day work. There may be more context given when answering questions around evaluating success of a design and ensuring designs are accessible.
• Role will relate to the role of the individual being interviewed, not to others in the team. This will allow for further content and understanding to the answers given by interviewees.
• One example would be when a participant explains that their role is as a Product Manager who oversees development of new features.

Testing

• Testing will relate to any tests done in relation to understanding the level of accessibility and conformance to guidelines.
• This should be identified as a result of asking participants how they ensure that their interfaces are accessible. It may also be a result of the questioning that asks participants how they evaluate success.
• This topic will only relate to accessibility and usability testing. It will not relate to any testing of front-end components to ensure compliance with business logic or stakeholder requirements.

7.3 - Developer Interviews: DPDM Transcript #

Interviewer: Ok, should be going… yeah, cool. So I was wondering if you could start by telling me a little bit about your day to day role and some of the main aspects of your job?

Interviewee: Ok, so I’m in the digital team in the [redacted] marketing department and within that team, I’m the team lead and then we’ve got 2 front-end developers and then 2 user experience designers, one of which is/was my previous role, so that’s what I started doing. Well, I basically, actually no - we’ll come back to this bit. And then we also have a search advertising and analytics specialist, which is kind of like - three jobs in one basically, but yeah that’s kind of us, six of us within the digital team, marketing. And then we work alongside a lot of the other people in the marketing department, so people who are doing things like content for the [redacted] website, or email communications for [redacted], stuff that goes on digital screens… things like that. We kind of, sort of do two main things, which is mainly like running the underlying systems, the content management system that the [redacted] uses to put content on the website. That’s our team that runs that, but then also we like, how does that get used for the things that people are building for it. So making sure that, you know, things are being built with users in mind and that it all hangs together properly and that there’s central journeys for it and that we’re doing things in an accessible way and usability testing and things like that.

Interviewee: So it’s kind of, yeah, split a bit between running the actual systems and making sure that the actual stuff that comes out of them is good, is good. And then a lot of that, within marketing, working with content specialists who might be doing [redacted] or research comms, or things like that. Or it could be people out in departments as well. So there’s lots of people, it varies a lot from department to department. Some have lots of people doing web stuff, some don’t have any, some are very skilled in it and have their own developers, some are like an [redacted] person doing it alongside other stuff. So we’re sort of trying to support them as well and make sure that, again, the stuff they’re doing is up to a good standard and uses the right visual identity and fits together nicely and isn’t broken basically.

Interviewee: A lot of the stuff… but basically I started here 13 years ago today, back when there was basically two of us doing all of that stuff, so yeah, a couple of us started when [redacted] got its first ever content management system and that was kind of, the start of trying to use slightly more modern systems and getting a better handle on what everyone was going. My job has basically kind of evolved as the team’s grown and the marketing department has existed and more people have been doing stuff on the web and even, when my job title was Senior User Experience Designer, I was still doing a lot of the other stuff, running the CMS and things like that because, possibly just because I’d been here the longest and I was the one who knows how to do the stuff. And then, kind of day to day, it’s supporting people with different projects they’re doing, whether that’s kind of at the user needs end of kind of, figuring out what do we actually need to solve on this thing to like, who’s it actually for and what are we doing, to like, the actual build and making sure it looks right and that there’s no broken links and everything is spell checked right and all of that stuff, so kind of, some of the double diamond stuff that came up last week - we kind of span quite a lot of it and sort of sometimes, come in at all different ends of projects depending on when people have started thinking about us.

Interviewer: Right, that’s interesting, so I was going to ask you… I had another question lined up, but I’m going to ask on the back of that, how do you try to accommodate the different range of needs there? You said that some could be admins who it’s their role to do it, whereas others are more trained and have a bit of background in it.

Interviewee: So, there’s a few different angles we tackle it from. Some of it is just documentation and just trying to make sure like, if there is a standard process, that we’ve written it down and we know, not everyone is going to read the documentation and sometimes that’s really just there for us to then remind ourselves that this is the process that people should be following things.

Interviewee: A lot of it just comes down to though, things in the tools themselves like the CMS, making sure that you know, if there’s a field that someone can type stuff into, it’s got sensible character limits set and if we don’t want them to you know, insert lots of formatting and stuff that we’re only giving them the options to put like bold and italics or things like that. Yeah, so I think a lot of it is just trying to put constraints around what people can do.

Interviewee: Yeah, knowing that documentation they might not read it, they might not understand it, they might not find it even if they were looking for it, just trying to make the tools in front of them as much as possible. But there’s challenges there though because the system we use it’s from an external supplier, so it’s not something we’ve built in house, so there’s lots of things where it does the thing it does and we don’t really have any control over it, so there might be fields that users see but we don’t want them to fill in, but because they’re just there in the interface and they look like ‘I should touch something in this box’, or ‘I should tick this box’, they often do. So then a lot of us is trying to just make things as resilient as possible, so knowing that people might break things but if they do break it, it doesn’t break the whole website, it kind of fails in a more graceful way. As much as we can put help text that people are going to see in the interfaces themselves and then there’s also like the training they get before using things which we’re a bit light on to be honest.

Interviewee: Years and years ago we used to run training sessions on like writing for the web and just how to use our systems, the post we had for that doesn’t exist anymore so it’s been a bit more self-paced stuff, so we give people like a PDF guide to work through. But again, it’s a bit hit and miss as to whether they follow it properly or follow it right. So a lot of the time, it’s just when people do have problems then helping them recover from those and just whatever we can really to, regardless of whether you don’t know what you’re doing or whether you’re a pro at it, you can, there’s as few barriers in the way as possible and it gets closer to it just being obvious by the system that you log into or what options you get there.

Interviewer: Kind of off the back of that as well, it’s not that you only design for, in… not only in house, or the admins, or departments… but then you’re also trying to make a system that’s accessible to a whole range of students and age ranges, so how does that work as well.

Interviewee: Are you thinking about the published website stuff?

Interviewer: Yes, so in your content guidelines, how do you try and cater stuff to be relevant to such a wide audience?

Interviewee: So like [redacted] has a style guide, which sort of tries to cover sort of some of that stuff, but a lot more of it is like nit-picky sort of details about… it’s campus east, not Heslington east and that kind of stuff, but then there are things that like our content teams have put together on tone of voice, tools to use like Hemingway, I don’t know if you’ve come across that one, it’s just like this online, sort of, clear writing checker so it’s, yeah, it’s one of our kind of go to tools if anyone’s written something, the first thing I usually do is paste it into that and it will often highlight everything in red and say this sentence is really hard to read. It just kind of does the same stuff you might do in Microsoft Word, but in a more easy to understand way where it’s basically saying you’ve written this for a 25 year old, it’s actually meant for an 18 year old and you’ve used too many adverbs here and you’ve you know, this sentence is too long and we don’t always agree with what it says because of like the [redacted] context we’re in. Sometimes we have to use complicated words and if you were talking to, I don’t know, a master’s audience, you would use some more complicated terminology than you would an undergraduate who’s still in school. So there’s some things, but mostly around the area that’s more centrally managed content that’s being produced within the marketing department.

Interviewee: These guidelines are available out in departments but we don’t really rigorously make sure that people are following them. We’ve just started using a tool called Siteimprove which is like this website checking cool where you basically point it at your entire website and it basically tells you what you’re doing wrong in terms of like, content quality, whether there’s broken links or there’s spellings and then also accessibility, SEO stuff as well. We’re kind of early days with that and we’re just using it within our team at the moment, but longer term that would be a tool that basically anyone within the university could have access to, so they know that what age range they’re writing on their pages and whether they’ve spelt things wrong and how accessible things are. There’s things like that and then on the broader accessibility front, we’ve been doing a load of work within the last year in our team basically making sure that all the templates and things we’re providing are within a decent baseline standard.

Interviewee: Lots of things with automated testing tools and manual testing as well, so taking sample pages and making sure that they’re keyboard accessible and that any keyboard contrast you can’t automatically detect, that we’re manually testing those. We’ve kind of got to a point where we’ve fixed most of the issues with the templates themselves but then you’ve still got all the issues with the content which might just be because someone’s used headings wrong, or they’ve not put alt text on an image where they should have, which are the ones where ideally the tool they’re using, like the CMS would help them with that stuff, but it’s not that great for that, so it, again, it’s more like documentation of this is what it should do. Making sure that if there are guidelines, that we can put in the tools themselves, that they are there. So you know, saying ‘write some alt text in this page’, ‘this is what it’s going to be used for’ and then having the fallback of these testing tools that can then say, ‘you’ve missed this heading’, that kind of thing.

Interviewee: And then things we’ve only really done bits of pieces of is actually testing it with actual users, whether that’s people who do have disabilities or just anyone, that’s the bit that often gets skipped a bit, but is usually the bit where you do see the thing of like, ‘this thing is really hard to use’, because can actually test it with real people. We’re trying to get more into that and that just being a regular thing that happens as part of any content or development project. Especially, where we are with lots of the target audience, they’re here. We don’t really have an excuse of ‘they’re hard to recruit or they’re hard to get to’, that you might have in other organisations. I feel like, we’re kind of, we’re getting there, but it’s like, there’s only so many of us within our teams that can, kind of, support and enforce this stuff so a lot of it’s kind of doing as much as we can to help all the other people around [redacted] be a bit more self-sufficient and just yeah, helping them kind of understand the principles of you know, designing for accessibility and things like that, so that they have a bit of, they’re not, we’re not going to expect them to understand WCAG guidelines or anything but just that they have an awareness that not everyone has the same abilities and that if we do things in standard ways then it’s easier for everyone and not to go out and procure crazy systems that aren’t going to be accessible.

Interviewer: What do you think excites you most about the work that you do?

Interviewee: It’s always varied which is good, I don’t think that I would have stuck around here for so long if it had been the same stuff for the past 13 years. I think that especially within our department, we’ve kind of been growing a lot more. [redacted] didn’t have a marketing department 3 years ago, we had, I was in like what was the communications department at the time, but marketing wasn’t really a thing that [redacted] thought it needed to do and there was like, back then, there was just lots of people doing the stuff around [redacted], but not in any sort of central team, so we were kind of doing our bit, people in IT were doing their bit, people in other departments doing things.

Interviewee: Then it was 3 years ago we got restructured into this marketing department, which, at the time, was like 30 odd people and now it’s 50-ish I think. That’s like bringing together us and content people and designers and so I think we’re kind of getting to the point where we’re doing things properly in a bit more of a structured way, rather than it being these things that kind of just happen in these pockets around the iunviersity so just a lot more, kind of, oversight and knowing like, these are the important things to focus on and how different projects relate and who needs to be involved and, so it, yeah, it’s good now being in a big central team where we’re working with content specialists and project managers and front-end developers and lots of people who we can kind of, trust to do the bit they know about, which web didn’t really have 3 years ago. It was just me, trying to do a bit of UX and then also a bit of design and maybe tinkering with a bit of javascript, so just kind of doing things in a proper way - that’s good.

Interviewee: Having, kind of, reliable processes - some of the more boring things, but just knowing, like, these little steps that we have to follow and this is what [inaudible]. So there’s that side of things, but then also in the environment that we work in, it’s interesting stuff that’s going on around us, all the different [redacted] and things, people doing cool, amazing things and [redacted] often like, sounds a bit pompous, it’s like [redacted] but some of it literally is, so, yeah… doing the little bit that we play and communicating that or supporting that kind of thing, that feels like a good, like, worthwhile thing to be doing and you know, making sure that all that stuff is easy to use and accessible and usable and it’s not going to get people into trouble with GDPR things and the process.

Interviewee: Yeah, that kind of stuff and then just kind of, me, personally, I kind of have always kind of had like an interest in the design side and the technology side so just the kind of stuff that we kind of get to do is kind of stuff that keeps me interested and there’s always new stuff as well and especially, again, coming back to as we’ve been growing and recruiting more people, for a long time it had just been people who’d been at [redacted] for ages like people like me, who kind of just know how CSS worked like 10 years ago, but then we get new people and it’s like there’s these new frameworks and there’s like, these new tools that I’ve never heard of, because I’d kind of just figured it out as I went along where as it’s now people who might have actually done a UX qualification and things like that.

Interviewee: So yeah, still being able to learn stuff and just things like within our department, we do things every couple of weeks, which we call a learning lunch where we pick a video and we watch it all together as a team, things like that that keep you learning things all the time, it’s just, yeah. That kind of stuff that keeps you interested. And all the random challenges, like [redacted] and “quick, we need to put an alert on every page on the website”.

Interviewer: What do you think are the most challenging aspects of designing user friendly and accessible interfaces?

Interviewee: I think certainly places like here, it’s not so much the designing it, it’s convincing other people that’s the right design, so there’s like any big project here, it’s gonna have lots of senior stakeholders who might have had their own ideas about how something should be implemented or what the solution should be, so I think like within our team we’ve got lots of talented people who can come up with the design but it’s usually the challenge of getting the more senior stakeholders to either buy into the idea that we need to go through that whole process or that the thing that we’ve designed is the right thing as someone might have had an idea in their head that they’ve seen, they’ve seen some other [redacted] do it so we should just copy it and trying to get people engaged with the process and so you’re not just kind of going off and doing your bit of design and then go, “ta-da, here’s what I should do”, because that’s the bit where they go “no, I don’t like that” or “I don’t like that’ and it’s more like involving them in the progress and we might get them exposed to users and hearing user feedback and helping them actually understand the more intricacies of the problem because the thing they might have come up with as a solution might be, a high-level surface thing and if they’re a bit more exposed to like the actual users and the problems they’re having then they probably empathise a bit more with the solution that your coming up with.

Interviewee: I think that’s one of the things that has taken me longer to realise that it’s not just being able to design something that’s good and great, it’s getting everyone else onboard and especially here when it’s, there’s like loads of different departments and so it’s like, there’s IT, there’s the academic apartments, there’s like central support services and things and lots of people who may have developed their own things in the past and having to convince them that maybe the way they’ve designed it isn’t that great for users and there’s a simple solution and it’s more to that just in general human nature thing that if you’ve built the thing yourself, it’s really hard to see what’s wrong with it.

Interviewee: The more softer skills of helping them see it themselves like why users might be having problems with it, rather than you just saying ‘what you’ve done is wrong’, which is probably what I was doing 10 years ago, just going ‘why have you done this so badly? It’s obvious I can redesign it and it’s going to be amazing’, them just not listening because they’re so attached to the thing they’ve done themselves. Same way around if someone else just came and told me the thing I’ve done is rubbish, I would just be no, my gut instinct would be to shoot them down. That’s one of the hard ones.

Interviewee: Then there’s also just, just the resource thing of just we’re, even though we’ve grown quite a lot, we’re still quite a small team. We’ve grown mostly in content production in marketing, so there’s like loads and loads of people who are content producers writing stuff for the websites, social media and using videos and all that, but our digital team hasn’t really grown at the same speed and that. Also, just cause people have moved onto different jobs and things, we’ve permanently had one role free in our team and we’ve never been up to full capacity, so we’re still building on all this, it is just within any big organisation you kind of have to make the case over time that, you know, this bit of investment, if you made this more investment, here’s what else we could do.

Interviewee: So many, so many competing things as well like, there’s so many things [redacted] does so many different things, it’s not like we just do one thing where we have to like sell a number of X. There’s [redacted], there’s [redacted], there’s internal comms, there’s [redacted], there’s reputation management. All of these different things and there’s always random spin-off things that come from [redacted] and independent businesses too that we’re trying to support, so yeah, just having the capacity to do the work across all of those priorities even when we are kind of could do the right thing if we had enough time, it’s just there’s too many projects. With these things, it’s like the never ending challenge. Does that cover all of it on that?

Interviewer: Yeah! And when you’re, might have covered this before, how do you understand new projects to work on? So if you’ve got a new interface that you’ve got to design, where do the requirements come from? Is it senior stakeholders, or…?

Interviewee: So for things we do in our team, we don’t tend to do interface design that much ourselves. We probably more help out people in IT services who are more likely to, they might be building that sort of thing but there’s been a few projects on where we’ve kind of helped them rather than us designing things for them. In IT services they’ve got like, loads of developers but they don’t really have any designers, well they don’t have any designers. Some of the developers have design skills but people there have are recruited more as developers, they’re starting to change a bit, so like, they’ve just been advertising for a UX Researcher and they’re going to grow that within themselves.

Interviewee: But yeah, in that context it’s more like they have business analysts and project managers who’ve done some analysis where they’ll understand the requirements and then that gets passed onto developers and I think, depending on which teams it might be that they do proper agile stuff, doing stuff with backlogs and stories and then just more, more, making things up as they go along. Some might have just a big list of requirements, 100 page spec that says this is the thing we need to build. It’s all a bit varied depending on which bit of [redacted] that it is.

Interviewee: Because we don’t really have any standard project methodology and things, it’s just the skills that happen to have in various teams and so yeah, people have come from somewhere else where they have been doing more agile stuff, that’s what’s tended to happen rather than it being an official [redacted] thing. So there’s some of that stuff, but the things that we have helped out with coming back to the resource thing, where they’ll have these big massive long 6-month projects, or even longer so things like designing the [redacted] catalogue is one that’s been a big ongoing project, which like all the [redacted] and things, the system that manages that which previously has just been like a load of word documents, so they’re trying to build like the actual system to manage that, which is really complicated because every department has their own rules and things, so they’re trying to then build an interface for that.

Interviewee: Because we didn’t really have the capacity to help or time with the design, we were more just trying to give them some skills where they could then figure it out themselves, like I ran a couple of sessions with them where we did some sort of mini-design sprint kind of things, where we were just doing like, things like crazy eights techniques where, you know, fold a bit of paper into 8 segments and then say, now we’re talking about you know, if someone wants to propose a new module for their course, what’s the interface for that going to be like and we’d all just like spend 5 minutes in silence drawing some really rough ideas and we’d all show the ideas and then do some sticky notes on the good, and then spend like another 15 minutes on doing a more refined sketch each and then doing a bit more voting until they kind of refined it to like “this looks like an actual design”. Rather than like, leaping straight into like, “there’s a requirement that says someone should be able to do this so I’ll just wing it”, so just trying to get them into more, just the sort of thought process around like there’s going to be more than one possible solution to this, so let’s do these kind of exercises that get them all out on paper and let people who aren’t thinking of themselves as designers as people who still have input on that, so business analysts or developers, they still understand like the requirements and the systems and the business processes that are involved so the stuff that they’re giving is probably more valuable than me going, “this box should be like 10 pixels taller” so that’s kind of like the polish on the end of it.

Interviewee: Then there’s the other bit which is one of the things that we manage in our team is [redacted]’s pattern library, so it’s like a central repository of components and things, actually I can show that. The idea with this is that we’ve got all these things that we can just provide to people so you know, if you want to put a button on something, then you use this, rather than designing your own button. So yeah, so we’ve, over the last few years been developing this and it’s still like a work in progress basically, but this is like the whole, sort of, starting from like the basic grid layouts that we have, through to then like, all the individual components, so yeah. Before we had this, we did a bit of an audit of all the different types of buttons that were in use on the [redacted] website and there was like 100. Maybe we don’t need quite that many, maybe we need some for like ‘Delete’, so yeah, standardising these kind of standard components that people are using so that we can kind of do some of those rough things, while we’re sketching out ideas but when it comes to actually building the things, they’ve just got the ready made components that they can pull in to things. We know there’s still quite a lot of gaps, but for most of the basic things that people are doing, alerts, forms, buttons, text things, there should be stuff in there that at least gets them started and lets them build something that’s going to look like it’s part of [redacted] rather than some other sort of random design.

Interviewee: So yeah, most of the time it’s that kind of stuff, where it’s like other people building those kind of interfaces and things. More of the stuff we tend to do is like, what’s the actual page going to look like on the website - whether it’s a course, or staff profile or a thing like that. The kind of interface to it, the thing we do tends to be more constrained by what the content management system does, it’s got some fields, we kind of decide what the fields are, but if it’s a select box - then it’s always going to lay it in the same way and we’re kind of stuck with those constraints.

Interviewer: So, I’m just trying to understand how it’s built. You have a CMS, then the component library, is that, is it more like a CSS framework?

Interviewee: So the component library, it’s lots of CSS and Javascript and then within the content management system, it’s like our implementations of these things, so like for example a course page for a prospective student, that’s going to be built of loads of different components, there’ll be sections with images and buttons and videos, which are all based on components from the pattern library. But then the thing that someone’s just using in the CMS, they’re just typing in the text that goes in those fields so as far as they’re concerned, they don’t even really know that this pattern library exists. They’re just using the pre-designed templates that we’ve just set up so courses, staff profiles, news articles. They’re all using these underlying components and they’re just, people using the content management system, they’re only, most of the time anyways, they’re only putting in the text or images that are going to go in those fields.

Interviewee: Sometimes we might have given them some options like maybe these icons can be displayed in two different colours, or you can have an alternative background colour on this row of text, but it’s from some predefined options that are in the underlying pattern library, so there’s like a course with colours, what’s the font, there’s [redacted] ones and then most of that is going to be predefined by what templates they’re using. But if you were like a developer in IT, you’d be working directly with the CSS and the HTML and the Javascript, copying and pasting most of that.

Interviewer: Do you use anything specifically for your templating, is it one of the templating languages?

Interviewee: It’s mostly stuff that we have developed in house, so all done by the content management system, so it’s… yeah. It’s not any, it’s none of the things that people have heard of. So when we were with IT, they were using React and things like that, but like that’s not what our things are in because we’ve like done the CSS bit, then we’ve got the CMS bit. If you want to actually like, use that in the system, it tends to be copying and pasting bits of code.

Interviewee: So it’s, I think there’s things we could do more of in the future to nicely publish it, along the lines of what your starting point was of understanding how developers need to be able to use this kind of stuff. So we kind of built it for our own need, where we could just copy and paste stuff into the CMS, but actually, we need things that can integrate with these other frameworks like React, or whatever it is that people build applications in. So that there’s like a proper connection between the things that we’re building and then the development platforms that they’re using so that we don’t still have this disconnect where you’ve ended up just copying and lasting something and it’s separate again and it’s out of sync and things like we do centrally, kind of permeate out because it’s a manual bit where you’re copying and pasting bits of code.

Interviewee: So yeah, I think it’s one of those things where we’re still kind of, maturing in what our approach is to those kind of things, so yeah, having the pattern library at all was a starting point so at least we have standard ways things should look, but how they get implemented, there’s a few more hurdles I think to just turn it into something that’s easier for developers to use whatever languages.

Interviewee: A lot of things as well, how much of this stuff is of interest, but we’ve done a lot more as well as to the kind of version control and version control stuff that goes with it. Going back years, it was lots of manual bits of HTML all over the place, but now it’s all in GitHub repositories and deployed with things like semaphore and stuff so all that kind of stuff is more rigorous and when we change stuff it goes through like, a QA process and gets deployed in a proper way that’s reproducible and reliable and that we, we catch bugs before they get into the live environment, so yeah, all that kind of stuff as well we’ve been, kind of, doing more of as we’ve been getting, as I said, getting people who’ve been doing this more, in more modern environments, building on what we do here within some of the weirder [redacted] constraints.

Interviewer: And I think we, maybe you started talking a little bit about it earlier, but how do you evaluate the success of the designs? So I understand that you have guidelines, but is there any measures that you use to say, this is a good design?

Interviewee: So, whenever we’re starting projects what’s supposed to happen but doesn’t always happen is people are supposed to be identifying what a success metric might be. Sometimes it’s hard because again, the environment we’re in, there’s not always going to be an increase in sales or something we can measure. So some of it are, some of the ones are guessing a bit of analytics things we can look at like increases in page views, or reduced bounce rates, but they’re always a bit of a guess as to whether… just because page views went up or down, it doesn’t necessarily mean success, either you could kind of put a little bit of a spin on those statistics either way really. So some of the stuff is often just around user feedback.

Interviewee: Sometimes doing like pop up surveys and things like that on things we’ve worked on, so, we’ve done things that have done purpose visit surveys, you know, who are you, what are you trying to do today, could you do it? So particularly on recruitment content, where we kind of know what the main things are that people are trying to do, like book an open day, or find out what the accommodation looks like or find out what the fees are, there’s usually an easy yes or no answer to that and then just trying to keep an eye on does that go up or down as a result of changes that we’ve made. It is, to be honest, it is a thing that often does get forgotten about and the success measure is just that we’ve shipped something and it’s live, onto the next project.

Interviewee: Yeah, we’re trying to bake it into the process a bit more, being a bit more iterative and doing things more as experiments, ‘this seems like a good idea, let’s try it with one of the pages, maybe try an a/b test’ and actually have some things that we can measure. So yeah, it is often just kind of retrospectively going, ‘so the page views went up, so that’s good’ even though that wasn’t necessarily what we thought was going to be the right measure in the first place. Some of the things were there really specific like we can tie them more to actual revenue and things so, like when it’s clearing and we’re doing loads of clearing advertising and things and we know how many people are calling the phone numbers, that there’s yeah, a lot more interest in making sure that you know, departments have got quotas to fill and the money that we’re spending on advertising is the driving traffic to the right pages and people on those pages are phoning and then going on to accept the courses. That’s one of the few times in the years where there’s like, there’s actual like, you know, we need to definitely know that we’re getting value for money where as I think often when it’s us as an internal resource people don’t really think that there’s money involved so they don’t necessarily think I need to measure it because we’re kind of ‘free’ because we’re, we don’t have an internal charging model or anything for the rest of [redacted] and there’s less focus on are we getting value for money by doing this thing, but yeah, certainly since we’ve had the person on our team who’s doing more of the search analytics, advertising stuff, been able to do more of the having goals in setup and analytics, this is the thing that we’re trying to achieve whether that’s sign ups for an open day or increasing time on page or whatever.

Interviewee: Just being a bit more specific about what the thing is that we’re trying to solve and just getting people to think a bit more at the start about what the problems they are, that underline the thing that they think is the solution. Within our team now, if anyone wants to kickoff a project, say someone wants to redesign, I don’t know, pages for graduation, the first thing they’d have to do is write a problem statement about what’s actually the problem of the pages now, rather than it just being kind of a “well we’ve redesigned them, therefore it’s successful” to like “this was a specific problem, we think by doing whatever” which might be a redesign, might be new functionality, we can solve that problem and then the next step of how are we actually going to know that problem did get solved and so it yeah, then trying to tie that a bit more to that might mean analytics, that might mean just people saying yes I can find the thing I was looking for, it might be a reduced number in support calls, it might be whatever depending on what the thing is, so yeah, it’s just trying to get that into the process from the start when people are first thinking about projects, because it’s a lot harder when we come to it at the end and people go “oh, can you tell us did this work or not” and we’re like “well we don’t really know what it was meant to do in the first place”.

Interviewee: So yeah, just trying to yeah, standardise those things and make sure that we and other people are following them as part of the things we do, some of that is you know, nuts and bolts things like we have templates for projects and so making sure that those things are in the templates and like even if it is like go and talk to whichever person that who knows about this thing who knows about this specific thing that you have to tick off within your project or you get to the next stage of building the thing which is always the tempting thing to do of I’ll start making some web pages, I’ll start tinkering and do a design without having done that. It’s a lot, it’s just having done those simpler things that aren’t always the interesting cool things, but just like writing down a checklist of make sure you talk to this person, make sure you think about this, make sure you think about how you’re going to measure it at the end which is going to differ from project to project but just having that as a thing that someone see when they start a project so that they don’t get to the end and then remember it’s a thing that they have to do. I’m a big fan of checklists.

Interviewer: So this next question might not be too relevant based on what we discussed earlier, but do you do any checks for accessibility and if you do, how do you ensure that designs are accessible?

Interviewee: Yeah, so that, that has been one that we’ve been doing a lot on the last year and yeah as I mentioned, a bit about the stuff we’ve been doing with Siteimprove, it’s another of those things of just making sure the things we know that we need to do, that they just get done. I think we’ve, so kind of historically, we’re in a pretty good state where we all knew bits about accessibility and we were kind of broadly doing the right thing even though some of the bits we might not of implemented quite right, in our team we had a pretty decent understanding anyways of lots of issues. But over the last year since the accessible legislation’s been coming in, we’ve been trying to get on top of it more and make sure that we definitely do know how to do things and they have been some of the things we’ve done where we’ve reimplemented things that we did years ago because they weren’t quite right, so, some of the more complicated things, like if there’s a tabbed in terrace, or things that have multiple states or alerts are popping up, making sure that those have been done properly.

Interviewee: I think we were getting the basics right of just like, yeah, doing headings, alt text and forms and labels and all those kind of things we were pretty good at that, it was the more complicated things that we weren’t quite as good at. So yeah, we’ve been doing a lot of stuff over the last year of just basically making sure everything that we provide through our templates ion the pattern library and the CMS are to accessibility standards, so testing all of those through automated tools and manuals, checks ourselves. So yeah, they kind of, so that we know the underlying things, then they’ll be as good as we can make them and then educating people who are then using those components and content types to use them in a sensible way, so that the things they put in have the right headings, have alt text and all that sort of stuff.

Interviewee: A thing, that more challenging bit, is like all the other stuff that gets put up around [redacted], like, because there’s a lot of other developers and people making all these other systems, which, I don’t think everyone will have had that necessarily baseline accessibility experience that we’ve had in our team, so I think some systems that [redacted] has, either that it’s bought or developed itself. There’s a lot more to do there and just education in those teams around how to make those kind of things accessible and yeah, I think that the tricky bit as well is that we can do all this work, like over the last year, there’s been this like, lots of audits and manual testing but then the thing I’m not sure about yet is how, in an ongoing way when we build like, new things, that we make sure that they stay accessible, because we’re not going to keep doing like, these big massive audits all the time, like that’s a once every few years type job because it’s such a big thing. Making sure how we can like put these checks in place so that when we develop a new component or template or something that’s been done in an accessible way, but also I think there’s probably some automated things that we can include in our build processes and things, because there’s like, there’s tools like AXE that you can. Integrate into the development workflows where they’ll like do some automated tests without you having to think about it, as well as the manual ones that we’ll have to like, do as a check. Any ones where it can just like, happen as part of processes that we’re doing anyway, I think that’s, that’s how we’ll make sure that things stays accessible if it isn’t something that people have to think of, the kind of things that you can detect automatically like you know, your colour contrasts aren’t strong enough, or you’ve used click here where you shouldn’t have done and things like that, that an automated tool can pick up, I think that’s gonna be the thing that’s gonna help us in the future I hope.

Interviewer: So that kind of brings us along nicely to the next question, which is what do you think the biggest opportunities or biggest challenges are for accessibility in the future?

Interviewee: So I think that we’re still in the challenge bit, I think of, there’s still quite a lot of persuasion that it’s even a thing that you need to like to bother doing anything about.

Interviewer: So would that be similar to what you were talking about with the stakeholders earlier?

Interviewee: I think there’s some of that, yeah, so I think some of it is very much the mindset of well no-one has complained about it or no-one has sued us so we don’t need to do anything about it, versus thinking about it more of the, well we’re just making in the same way as we did a usability test and we saw that something was causing problems for people we’d fix it, some of these people might be a bit more out of sight because we don’t see them in our kind of day to day work in our own little bubbles in our teams, so we’re just kind of not exposed even though it is like a huge huge numbers of people who might have any kind of accessibility issue, lots which you can’t tell because they’re not in a wheelchair and these things.

Interviewee: So I think just yeah, getting people to realise that these are things that affect loads and loads of people, it’s not just the odd person they’ve seen in a wheelchair. It’s yeah, it’s putting a barrier in place that’s like, you know, someone who might be interested in our courses, or giving a load of money to find some money if we’re making our website hard to use, we’re missing out on opportunities rather than like risking being sued as like the thing that people are thinking of at the moment.

Interviewee: But, there’s been lots of work particularly in [redacted]’s learning technology team that they’ve been doing, raising awareness and running lots of like, sessions on creating accessible documents and teaching materials and things like that, doing things like getting interns to work in departments to try and just spread awareness and stuff. They’ve been looking as well, so there’s lots of like mandatory training things that you have to do when you’re working at [redacted], like health and safety, fire safety, GDPR and all that kind of stuff and trying to make accessibility one of those so that people have a bit of an awareness that if you’re putting stuff on a website, or introducing new teaching materials or just sending emails or creating documents that there’s accessibility considerations, so there’s been good stuff that they’re just building awareness I think that this isn’t just about avoiding being sued, it’s about just making stuff better and easier for everyone and that there’s benefits if we do that you know, you make stuff easy for something, someone who has a specific impairment, but that just makes it easier to read for everyone, even if they don’t have an impairment, but they’re on a crappy network connection, or they’re on a rubbish old mobile or whatever. These kind of things benefit everyone.

Interviewee: But it feels like we’re, yeah, with the legislation stuff we’re definitely more, more awareness now and we’ve kind of, increasing out skills in building the right sort of stuff and it will be interesting to see how things pan out over the next year or so because I was watching a webinar the other day where there was someone from the cabinet office saying that the team that they’re assembling which is going to be responsible for enforcing accessibility statements and checking websites and auditing samples of the sector sites to see if they’re actually doing the things that they’re saying in their accessibility statements and what comes of that.

Interviewee: I think one of the big challenges is going to be the amount of different systems that we have and I think it’s still not completely clear just the extent of where this legislation ends because it sort of started sounding like it was just public sector websites but its now evolved to if its on the web than it should be accessible even if that’s just an internal tool used by a few members of stage, like the same standard should apply to that and those are the things that are often harder to fix because its external supplier or its someone worked here ten years ago built it and they don’t work here anymore. Yeah, it’s like, because we don’t really have a website, it’s lots of, there’s the bit we kind of control that comes out of the content management system but then there’s all these other systems that have either been built locally or bought in from external suppliers or been internal at one point or whatever or that someones just randomly set up on Wordpress themselves.

Interviewee: So yeah, we’re, it’s a challenge for all sorts of things like, GDPR and advertising claims that we make and just you know knowing what our entire digital estate is because its over the years, its has been very organic in how its all grown and so lots of people have done their own thing and trying to rein that in a bit more while still letting people do good stuff, but making sure that they’re doing things that aren’t going to get us into trouble and… or get them into trouble or just, even if we’re not going to get fined but end up in some student press scandal, because… yeah. A lot of stuff we’re doing it with good intentions but then there’s just, coming back to some of the capacity things and relative priority things, we’ve spent a load of time over the last year on accessibility stuff we could spend all of this year as well on it, but there’s like other projects we’ve got to move onto so we’ve kind of got to accept that there are going to be you know, thousands of PDFs on our website that are still inaccessible that we’re not going to fix because it’s just too hard really with the resources that we’ve got.

Interviewee: But I think that some of the legislation stuff, it is a bit more of a, a bit more of a tool that’s going to help us win some arguments with people, like “maybe we should like just get rid of this thing because it’s inaccessible and you’re not maintaining it any more”.

Interviewee: We’ve got so many pages on our website, we don’t know how many pages we’ve got basically. It’s like, probably about 100,000 but we’re not quite sure. So yeah, all of these, all of these legislation things do kind of help us with the argument of like making g people think things through properly of what’s this content for and who’s going to maintain it and whether it needs to be removed.

Interviewee: So I think there’s some side effects from doing accessibility work or GDPR work that mean we just have a better oversight of what’s on our website and who’s doing it and who’s maintaining things and, being able to make the case for like having more resource in our teams to just be able to do all this work and do it properly. Because yeah, that is often the thing that some of the stakeholders might listen to more, is, when there is facets and external actions, even if we keep saying the same thing for years, that might be the thing that gets people to listen. So yeah, even if it often is the thing that we should have been doing all the time anyways, it sometimes needs these things to do it. But it is, yeah, it helps us with some of the things that we’ve been trying to do with the pattern library - just making things more consistent.

Interviewee: Making all these different people around [redacted] do things in more standard ways, will give us more of an argument behind that of its not just us imposing something which sometimes is the impression that people get, its like marketing telling us what to do. It’s not, it’s us trying to help by giving you the right tools that you can use that are going to make sure that you’re on brand and doing things the right way - it’s not about stopping you from doing the things you want to do, its doing things in the right way and that comes back to the thing earlier - there is all this exciting stuff going on around here and lots of people who are new are like “I’ve got this research project and I want to set up a website for it” and then they just go off and do it without any oversight centrally and then we, and then end up in all sorts of problems because like after the project funding runs out, no one maintains that website or things that happen all the time is that the domain name expires and now there’s porn on that website.

Interviewee: These are all the other kind of things that keep me busy alongside people like UX stuff, it’s like oh we seem to have porn on this .ac.uk domain, can you remove it very quickly? So yeah, I think all these kind of things help us sell the case for like standardising things more than just doing things in standard ways and that kind of then give us more time to do exciting things that aren’t fixing all these little problems because which kind of come from the root cause of people doing things in inconsistent ways in the first case. Accessibility I think is one of the kind of levers behind that and one of the things that we do better as a result of doing things in a standard way.

Interviewee: So yeah, I think that we’ve kind of got our stuff into a good place, I think, and with this Siteimprove tool that we use it gives us like, a score which is a bit made up because its just based on automated tests, so there’s loads of things it doesn’t know about, like whether the site is keyboard accessible, but it gives us a nice number, where we can say we’re 88 out of 100 for accessibility and it shows us how we can compare to the sector who are still on like 60s, so by doing this work we’ve got to a good place and that helps with SEO stuff as well, so it kind of all feeds into different things.

Interviewee: Just the other challenging bit on accessibility is as things get more complicated, like more complicated interfaces and things those, knowing how to do those right is harder I think and there, like often when its things we’re trying to solve on the web it’ll be things that someone else has already solved like if we’re going to do a tabbed interface or form or whatever, you can kind of look what’s the best practice for this? Someone will have already solved it, but as it gets into more novel things like… I don’t know, like, we’ve done work an online campus map - that’s a thing that our team does…. Those kind of things where it’s more of an interactive, especially when it’s on mobile and it’s dragging multiple finger gesture kind of thing, how do you make those more accessible, those are the ones where it’s like “hmm don’t know”.

Interviewee: Yeah, especially as you try and do these more app[lication] like things, that aren’t just rigid, it is a blind thing, it gets a bit blurred of when it stops being a website and starts being an application. How do you make those kind of things more accessible, that’s where it gets like, yeah it gets trickier and gets certainly outside of the things I kind of know how to definitely do, those things that I think no-one knows how to do because its technology that’s still kind of updating all the time.

Interviewer: Yeah, because I guess you kind of, you want to explore the stuff but then there is a little bit of fear there that its not accessible the way it needs to be accessible.

Interviewee: Yeah, like with the map, that’s an interesting one because the legislation like specifically says like maps are exempt, so your map can be completely inaccessible but that’s rubbish so you like, it kind of acknowledges that kind of stuff is hard to make accessible but then that’s a bit of a cop out really because you’ve done this cool map, but you can’t use it though. So like we’ve, yeah we still kid and do as much as we can in the context of make sure the colour contrast are fine, but yeah, they’re all things where if you can’t, you know, squeeze to zoom in and out I don’t know how you would interact with that. And yeah, some of the legislation says like your map can be left out as long as you’re proving directions in a different way, but then that just can be like a load of text to say “walk across the bridge, open the door, go up the stairs”, that doesn’t seem like a particularly modern experience.

Interviewer: Pretty crap to be honest. One of the things we noticed at [redacted] was that we were showing a graph to somebody that was a representation of this data that was in a table below and we were told, ‘oh well don’t worry about the graph if blind people can’t see that, just take them straight to the table’ but its like ‘well there’s information represented in a way there in the graph so that it’s easier to get’ so if we don’t give that to the client it’s like they’re not getting that same experience.

Interviewee: I think that one of the things that is hard for people to get is when youre doing things like that or alt text or anything, you’re not necessarily representing the information, it’s more of the meaning and I did hear a thing that summed it up really nicely the other day, I can’t remember what it actually was. It was one of the alt texts where like, one of the things that people often do wrong is, well ‘wrong’, they’re describing what the picture is of, rather than what the picture is conveying.

Interviewee: So there’s loads of alt texts that say, the one I use as an example is like a little map with a pin showing where York is and then the alt text that someones put on the is, ‘graphic showing the map of the UK and the location of York’, the thing that’s actually conveying is that York is in the north of England and that’s what the alt text should have been. The fact that it’s a graphic the fact that its a pin is irrelevant if you can’t see it and just trying to get that, yeah, that subtlety of your conveying the thing that this is telling you, is telling someone without it necessarily being worked for word or exactly the same data as a graph, the thing you’re trying to show might be the trend or the difference between things. It’s not just the same as here’s all the numbers that went into the graph.

Interviewee: Yeah, those are the trickier ones where you need, where like automated tests can’t really do anything, they can go “well there is some alt text” or you’ve used the right value but providing the same information or experience is the bit where there’s gotta be some manual testing and this then the more time consuming bit and the bit that often gets skipped because its harder.

Interviewer: Well I think that’s all the questions that I had for you, I was just wondering if there’s anything that you think I might have missed, or anything that you think would be good for me to know?

Interviewee: I think that feels like I've poured quite a lot of my head.

Interviewer: It’s been really, really good, I really appreciate it!

Interviewee: Are you talking to many other people who work around [redacted], or?

Interviewer: Not around [redacted], it’s pretty much just been you from [redacted]. The rest have been local developers, so yeah, it’s been good to get some snapshots of different industries and how accessibility plays a different role, it’s been good.

Interviewee: Yeah, I think the NUX events are really good for that as well, random bunches of people you wouldn’t normally cross paths with. Yeah, so like I think everyones in their own little bubbles of how we do things in our sector and, yeah, think that’s why it’s always good to have those meet-ups and get people from different spheres to see how they’re doing it because it’s very easy to keep doing the same thing.

Interviewer: There was somebody at the end of the talk, when, who was like, “ah, we always get funding that’s not a problem with the product” and then somebody on the other side of the room was like, “no, that’s not the case, we don’t get that”. So yeah, it is funny to see just how different it is. Then even within [redacted] there’s someone who said they’d never heard of, they spoke at the end and said “I’ve never heard of [redacted] and I do [redacted]”.

Interviewee: Yeah we’ve got lots of different pockets of things going on, so it’s not all like joined together. We’ve done a few bits and pieces which have been good but, it doesn’t broadly happen. At [redacted] where we’ve got central support departments and then academic departments, but never those making use of each other’s skills. So, yeah, there’s like people who know about UX stuff and, or, about making videos or whatever in our departments but we don’t, I mean sometimes it is just because they’re focused on the research project they’re doing and taking enough time to talk to us about things, but where we can make use of each others skills I think there’s, yeah, definitely things we could learn more about.

Interviewer: Cool, I’ll stop the recording there.

7.4 - Developer Interviews: UXRL Transcript #

This interview was conducted by email.

Interviewer: What do you do in your day-to-day role? What are some of the main aspects of the role?

Interviewee: My job title is “UX Research Lead” in a specialist digital accessibility agency, so my work is focused on people with disabilities. I do a number of different client projects, including designing and conducting user research studies for clients. This includes study design, recruitment, moderation, results analysis and deliverable production. These studies might be exploratory research, like contextual inquiry, or evaluation, like usability studies.

Interviewee: I also do accessibility strategy consultancy, working with client organisations to understand current state of digital accessibility, and help them develop a strategy and supporting actions for improving how they handle accessibility.

Interviewee: And I do a lot of accessibility audits, evaluating web sites and apps against accessibility standards, providing recommendations for addressing the issues we find.

Interviewer: What excites you about your work?

Interviewee: The real value of our work is helping organisations reduce inequality by making it possible/easier for disabled people to independently complete tasks and achieve goals using the organisation’s digital products. There’s an educational and motivational aspect to our work, changing attitudes from “tell us what we need to do to comply with the law” to “how can we make the user experience even better for disabled people?”

Interviewer: From your own experience and from working with developers, what are the most challenging aspects of designing accessible and user friendly interfaces? Why?

Interviewee: A couple of things:

Interviewee: Development processes often forget about accessibility until late on. So when people realise that accessibility is important, that issues exist in a product being developed, it’s harder to fix those issues with the available resources and budget, because of decisions that were made earlier on and now can’t be unmade. That might include having to deal with a third party tool, development framework or other tool that was selected to supposedly make the digital product easier to create, but is horribly deficient in accessibility support.

Interviewee: There’s a tension between adding more functionality and providing a simpler user experience—too many people value the former over the latter, and complexity makes solving accessibility more challenging

Interviewee: Products that are developed without a real understanding of the needs of disabled people, who may not have been involved in any user research or evaluation. So we’re trying to make recommendations for improving accessibility based on the results of a conformance review against WCAG, when the best thing is to do would be to observe disabled people trying to complete tasks, to figure out where the critical usability problems are from a disabled person’s perspective.

Interviewer: When thinking about designing and implementing a new design or feature, do you have a recommended process for doing so?

Interviewee: Start with understanding user needs in terms of the real-world goal the feature is intended to allow; find out what approaches work best, and select the best approach for meeting those needs. Follow accessibility guidelines at all stages of the design process, and make sure that all of the product team (visual designers, content authors, media producers, developers, testers, project/product managers) understand the importance of accessibility and their role in ensuring it is properly addressed.

Interviewer: When working with user interfaces, how do you evaluate the success of a design?

Interviewee: Ultimately, a usability test with disabled people will help confirm whether task completion is possible, and if so, if it’s easy. If not, refine the design and improve.

Interviewer: How do you ensure that the websites you work with are accessible?

Interviewee: I don’t develop web sites, and as a consultant, all we can do is provide the best quality advice and support that we can, and hope our clients follow it.

Interviewer: What do you see being the biggest opportunities or challenges for accessibility in the future in the field?

Interviewee: Opportunity—an increasing realisation, especially with the COVID-19 pandemic, that access to online information and services, and thus digital accessibility, is a civil right and therefore not an optional feature.

Interviewee: Challenge—the ongoing compunction in the tech industry to ignore tried and tested processes in favour of inventing a new process, toolset or framework that focuses on addressing a very specific set of developer needs and ignores user needs and especially the needs of disabled people. I’m also increasingly concerned about the political motivations of some of the tech industry, where right-wing free-market principles seem to be in conflict with the ethical, human-rights principles that should underpin inclusive design of the digital products that are so important to everyday life.

Interviewer: Is there anything that you think I may have not covered that you think may be useful to my research?

Interviewee: Your project talked about personalisation, and I’m not sure if that’s personalisation of the development experience to make it easier for a developer to integrate accessibility into their work, or personalisation of the application they develop, so that it’s easier to use by people with different accessibility needs? For the latter, I think it would be worth exploring how to help developers (and everyone else in the product team) better understand good user experiences from the perspective of people with a range of disabilities.

Interviewer: I just have one follow up question, in response to where you say: ‘There’s an educational and motivational aspect to our work, changing attitudes from “tell us what we need to do to comply with the law” to “how can we make the user experience even better for disabled people?’. What are some of the methods you use to motivate people about web accessibility? In my experience, it always feels that there is a lack of empathy with some product owners/developers and that they struggle to prioritise a user’s needs before deadlines and business goals which tend to focus on releasing as quickly as possible with as little development as possible.

Interviewee: Motivation is a good question. There are lots of theoretical answers, and the most effective method really depends on context and audience. Since I work for an accessibility consultancy, I have the advantage of working with organisations who have engaged us for help in some way. So to some extent they already have a bit of motivation, otherwise they wouldn’t have invested in our help. That said, sometimes paying for advice and taking that advice are two very different things :)

Interviewee: For example, when we do a conformance audit against a standard like WCAG, the focus is on reporting areas of non-conformance. That can make an audit look like really bad news, because by its nature it concentrates on reporting failures, and not things where the site or application is doing well accessibility-wise. To motivate people to act on the audit, we might:

Interviewee: For each issue, include a recommendation along with an estimate of the impact of the issue on disabled people and predicted effort to fix, to help our client put a prioritised remediation plan together. So if they can quickly see easy fixes that have high positive impact on users, then that’s a good place to start. Then they can figure out how to implement the harder fixes.

Interviewee: Identify examples of where things perform well, so that we can say “keep doing this”

Interviewee: If we are doing strategic consultancy, where we’re talking to people across an organisation, we might want to articulate the risks of not investing in accessibility (legal issues, people not being able to use an app, bad publicity, people choosing a competitor product) and the benefits of investing in accessibility from the start (reducing those risks and also improving user experience, improving internal processes and awareness of diversity of all sorts).

Interviewee: One tactic for motivation that we can see benefits and limitations of is the “accessibility is not just about disabled people” argument. It’s true that accessibility benefits lots of people (older adults, children, people with low literacy, people with situational impairments etc), and that can be persuasive for people who think it only affects a few disabled people and thus isn’t worth the investment. The downside of that argument is it diminishes the moral obligation not to exclude disabled people from access to digital technology. Saying “not just” implies that if there weren’t these other beneficiaries, then it wouldn’t be worth the effort. And obviously that’s insulting and diminishing for disabled people. So we’re really careful about that argument, and will always try to frame it as “reaching the widest audience possible”.

7.5 - Developer Interviews: AS Transcript #

This interview was conducted by email.

Interviewer: What do you do in your day-to-day role? What are some of the main aspects of the role?

Interviewee: I am an Accessibility Specialist at [redacted]. My main role involves performing technical assessments of websites and applications for accessibility, and this normally means testing against the Web Content Accessibility Guidelines (WCAG) version 2.1 (but there are other standards too, such as Section 508 in the US and the European EN 301/549 standard). I also occasionally provide training on creating accessible content, and guide developers through the process from the beginning of the design stages to the final product.

Interviewee: I have been working in this field for well over a decade – I joined [redacted] earlier this year after 6 years as a senior accessibility consultant at [redacted], and before then I worked as an accessibility consultant at [redacted].

Interviewer: What excites you about your work?

Interviewee: There are a few things I enjoy about my role. Firstly, I get the opportunity to review all sorts of different types of apps, websites, web applications and so on, so no two weeks are ever the same. Secondly, I think the technical accessibility speciality is quite a narrow field – there aren’t many of us around – so it is great for the soul for people to treat you as an “expert” (even if you’re just bumbling along like everyone else!). And thirdly, I try to think of myself as an educator – when I deliver reports to our clients, I try to make them educational documents rather than “You’ve done this wrongly, fix it”. It’s a great feeling when you start off reviewing a product that’s completely inaccessible in January, and then by December find everything has been more or less resolved and the developers are on the right track for future projects.

Interviewer: From your own experience and from working with developers, what are the most challenging aspects of designing accessible and user friendly interfaces? Why?

Interviewee: There are a few issues driving this. Firstly, a significant number of developers I encounter don’t necessarily have a formal education in web development. Those that don’t have often taught themselves from scratch from (say) a few online courses, while those who have learnt web development at university may have had little exposure to web accessibility. Coupled with this is that much of the “teach yourself” content online doesn’t always include accessibility, so new developers might not even be aware of the pitfalls (and some resources, such as Google’s introduction to creating native Android applications barely mentions accessibility at all). This means that a lot of web accessibility is learned “on the job”, which is fine, but not great when you need to push something to production at 4:55pm on a Friday afternoon and you know it’s not accessible!

Interviewee: For more seasoned developers, there are two issues: Firstly, the pressure to ship the product out as soon as possible, which often results in inaccessible content (where the developers can only fix the issues in a later sprint). Secondly, developers are not superhuman – there is often a lot of pressure on them related to (for example) designing, implementing, testing, security, privacy, and so on, all of which needs to be carefully balanced with ensuring the product is accessible. And this isn’t always easy!

Interviewer: When thinking about designing and implementing a new design or feature, do you have a recommended process for doing so?

Interviewee: I rarely do much development work these days, but – in terms of advising clients – we would always recommend that they think about accessibility from as early a stage as possible. In the old days, this used to be through (e.g.) paper prototyping, but these days you have collaborative design tools such as Figma, Sketch, and the like, where designers, developers and accessibility specialists can come in and comment on specific designs. For example, if designing an expand/collapse feature, it’s always useful for everyone to know straight away that the trigger control needs to be made keyboard accessible, and the appropriate semantics need to be relayed to assistive technologies (e.g. using the WAI-ARIA aria-expanded attribute). The more you can do this at the design stage, the more likely developers are to be more aware of it and therefore to build something that is accessible.

Interviewer: When working with user interfaces, how do you evaluate the success of a design?

Interviewee: I suppose you’ll get a different response from developers but, as an accessibility consultant, its “success” to me is how much it meets WCAG 2.1. That said, I say this with a massive caveat – WCAG 2.1 is really only a technical standard, in that it ensures that (in simple terms) your site will work with assistive technology X and Y, and will be understood/operable by people who use assistive technology X and Y. The nature of my job means that I am not always involved in user research, which should always be combined with any technical assessment. Yes, it is possible to develop an app that meets WCAG 2.1 but is not very pleasant to use (and vice versa, of course). So a user interface that passes WCAG 2.1 Level A & AA and which is also a delight to use is, to me, a success.

Interviewer: How do you ensure that the websites you work with are accessible?

Interviewee: Again, technically I’m looking at how much the site meets WCAG 2.1 Level A and AA (and occasionally AAA, but this is rare). If the site passes each of the success criteria, you know that it is more or less going to be compatible with the latest assistive technologies, and is therefore going to be operable under different browsing conditions. Nevertheless, as I said above, this is really only half the story – the proof of the pudding is in getting people who actually use these technologies to use the product. If you don’t do that, you can’t really be sure your product is accessible (in the usability sense of the word). If a client says to me, “Thanks for this WCAG review, does that mean my product is easy to use?” my answer is always, “I don’t know, why don’t you go and try to find out?” 😊

Interviewer: What do you see being the biggest opportunities or challenges for accessibility in the future in the field?

Interviewee: We’re slowly moving away from the idea of the concept of using only a browser to navigate the web. The success of products such as Alexa, Amazon Echo, Google Home etc. means that we’re interacting with the web in a much different way than we did ten years ago. Obviously, such products have helped in terms of making web content available for a lot of users – for example, a blind user no longer needs to use a screen reader to open an application and play a specific song, they can just ask Alexa to do so. Yet, they also introduce potential accessibility barriers; for example, a deaf person who may find it difficult to articulate and communicate clearly using speech may struggle to order something online. Can such products be designed so that information can be transferred back and forward using different input/output modalities?

Interviewee: Tied in with this are other issues such as privacy, security and safety. A person who uses an Internet of Things device may not want that device to know that they have a cognitive issue. Healthcare IoT is also a sensitive area which may have an impact on disabled people – can they trust the technology to work as they need it? The problem at the moment is that accessibility standards such as WCAG don’t cover such issues. How can we bridge the gap between accessibility, privacy, and security?

Interviewer: Just to follow up (if you have the time), where you mention that WCAG ensures that a site will be compatible with assistive technology, I was wondering if you might be able to provide me with a few more examples of assistive technology that you’ve regularly encountered? I’m aware of screen-readers and OS features, including those that are being introduced onto the web (such as prefers-reduced-motion). I have also encountered a user with a braille keyboard and a user with a foot pedal. Are there other technologies that you believe are frequently used on the web?

Interviewer: I resonate with your final point on the IoT privacy issue. It seems that to use these new devices/services you have to sacrifice another part of your privacy. I wondered if you had come across companies or products that handle the ethical side particularly well? It’s quite difficult to think about personalisation without considering all the ways that it could be misused (used against the user’s best interests).

Interviewee: Voice recognition software, e.g. Dragon. Apps of this type are often used by the general population in cases where people find it easier to use speech rather than to type text, but they are also often used by people with certain impairments too – from RSI through to (say) people who have more severe motor disabilities that means they cannot use a mouse, keyboard, or touch. One such example is filling in a form – Dragon allows users to announce (for example) “Click First Name” to move the focus cursor into the “First name” field (i.e. as an equivalent to clicking on the field using a mouse).

Interviewee: Screen magnification software, e.g. ZoomText. Apps of this type are often used by people with low vision, particularly in cases where the browser’s magnification features are not sufficient for their needs.

7.6 - Developer Interviews: UIDL Transcript #

Interviewer: So I was wondering if we could start, if you could tell me a little bit about what you do in your day to day role and the main aspects of your role?

Interviewee: Sure, ok. I am a UI design lead in a design systems team at [redacted]. I guess the only caveat that I’ll put around this is that my views here are my own views, they don’t represent [redacted] in any ways though I can imagine we’re sort of fairly aligned in our thinking, well I hope we are.
Interviewee: I work on a designs systems team, from an accessibility point of view the lovely thing about that is any change that you make is sort of propagated outwards. So all the components within our design system have been tested by the digital accessibility centre and by ability net. So, you know, they work on all of the assistive technology. We also have a copy writer in our team, a content designer, who is very big on plain English. We’ve been doing a lot of work with the national autistic society, trying to get their accreditation and a lot of that is just down to plain English and things being written in a way, that you know, people who read at a lower age, I think that we aim for like a, sort of, an 8-10 year old reading age, you know, doing that just means that it can be read and understood by everybody.

Interviewee: So the nice thing about a design system is any change you make is propagated out and our design system is multi-brand, so it’s not just [redacted]’s components. We have like a white label component that is skinned up for [redacted]’s, for [redacted], for [redacted] and for [redacted]. So any change you make to the sort of core component, it may be a button, a dropdown, any change is sort of propagated outwards so in terms of accessibility design systems are a real winner.

Interviewer: Right, thank you. So what excites you most about your work?

Interviewee: Solving people’s problems and helping people at the end of the day. I’m a designer within financial services which a lot of people see as a very ‘unsexy’ place to design. But money is a real enabler and really important to people whether that’s amassing a lot of it, which some people are quite excited about, to just being more prosperous in your day-to-day life that you know means very different things to very different people. For a lot of people it’s not all about having a lot of money, it’s about being able to live your life in a way that makes you happy and brings you closer to your family and fulfils whatever needs you have.

Interviewee: So by designing financial products which actually help people, help them with their lives, make them feel not so stressed out about their finances and that it’s something that’s a bit more manageable and means more to them, they understand it, it’s a nice thing to be doing I think. Especially within [redacted] it’s sort of the closest you can get to working for the Government without, with working for corporate. So I guess that’s why I’m here.

Interviewer: That’s really interesting, thank you. What do you think are the most challenging aspects of designing user friendly and accessible user interfaces and why?

Interviewee: I guess there’s a trade off between things looking kind of ‘sexy’ and ‘design-y’ and things being usable. As a designer I’ve, you know, kind of gone through the cool stage , obviously many years ago because I’m very old. Using very light greys and things, which look very ‘design-y’ and cool, but then, you know, the trade off with that is not everyone can see a really light grey line or, you know, can read your really tiny text which might look really cool to like a 20-something user. I think it’s not until you start sitting in on user testing, as you said, testing with a blind person or you know, I sat at the digital accessibility centre, I sat with their low vision team and just saw how they actually interacted with some of our form components. Things like a really light grey border, they just can’t see and you’re like uh I’m just doing people such a disservice by designing this kind of cool thing for cool points for the little designers. It’s very much a trade off between aesthetics (for some designers) and usability.

Interviewer: It’s interesting. I think one of the things I struggle with being on social media as well is a lot of that. When you look for design advice, the most popular stuff does seem to be aesthetics over actual practicality.

Interviewee: Yes. I mean I’m not a dribbble user because I just find that, this tiny little snapshot of this beautiful object on this beautifully coloured background in this situation where it would never be used by a real person. Yeah, it’s not very real to me.

Interviewer: Next question is, well I think you kind of touched on this earlier. When designing a new interface component, or feature, do you and your team have a process for doing so?

Interviewee: A lot of our things are kind of user-generated or user lead, we prioritise things based on a user need. It’s when something has been requested or you know, people are testing something and they need it refined, or you know, there’s a pattern that doesn’t exist in our library. That’s what tends to drive it in the sort of world of components certainly. Yeah, so it’s kind of based on the needs of our designer and developer and product owner, consumers, people who consume our design system and then obviously ultimately it’s coming from our customers.

Interviewer: Ok, right, so your team kind of design the component, then it gets implemented or does testing happen before implementation or…?
Interviewee: I guess within our design system, we only take in components that have been tested by the sort of, customer labs and user testing. Yeah, it’s kind of a bit of a chicken and egg thing, if someone has designed something themselves and it’s proved out really well in testing then we’re really happy to accept it. In some cases it’s just us doing a lot of research and then sort of, reaching out to other teams and saying ‘hey we’ve had a request for a progress indicator’.

Interviewee: We’ll look outwards to all of the industry leaders, GDS the Government Digital Service are kind of always my greatest inspiration for form components certainly, all their components are tested by the digital accessibility centre so you know that you know, they’ve been through quite a rigorous testing process. We have a series of labs on site which test things as well for us. We try and be as informed by all the learnings as we can and then we’re always changing and iterating [inaudible] there and back it’s not working and in light of this can you change it.

Interviewee: The thing with changing things with such a large system is any change is actually quite a major thing and I didn’t really appreciate that when I took on this role, it’s really important to sort of, take your consumers along for the journey.

Interviewee: When I first started I changed something really, what I thought was really minor, which was off the back of some research, an accordion we changed the plus and minus button to be chevrons which you think is just a really simple thing of changing two icons but we didn’t really take everyone on the journey with us. So there were a load of people going ‘Woah, why’s this changed? I’ve got this thing in development, what should I be using? Why are you changing this in the first place?’. So this tiny little change, since then we’ve kind of, we talk to people all the way through so we say ‘Hey, we’ve kind of done some research and we’re thinking of changing this. Has anyone got any thoughts on it?’, and then people will feedback to us and then we’ll take them along and then you know, if we make any change, we’re very you know, we sort of document it all and we say, ‘We’re going to change this. We’re going to change this on this day. We’re changing this today. We’ve changed this!’. I don’t think you can really tell people enough in a big organisation. Something always gets lost.

Interviewer: Right, ok.

Interviewee: Yes, documenting things. Change logs are always very important.
Interviewer: And earlier there you said sometimes users will request things? How do they go about doing that?

Interviewee: We don’t really have a formal process and that’s on our roadmap for this year. We kind of, we’re a small team and we’ve worked really reactively to date. So we haven’t really had an approved process for submitting things, it’s just like - get in touch with us and have a chat, not really scalable. We had an amazing graduate who came in and built us a ticketing system in Jira which has been really useful. At least, we’re kind of logging things now, you know, people can contact us by that. Our delivery manager will assign that to the right person and they’ll get in touch with you. That’s our, kind of, first step towards it. Within an organisation like [redacted], everything is really locked down. You just think, “ah I’ll just do it on GitHub and everyone can chat to you there” but not everyone has GitHub access, some people are using GitLab, some people are using some Microsoft thing, not everyone has a login. So there’s not really one place where you can talk to everyone and generate a conversation. So that’s a huge blocker for us.

Interviewer: Ah that does sound really difficult. It’s something good to be working on though!

Interviewee: Yeah.

Interviewer: So in regards to working on user interfaces, how do you evaluate the success of them in a design. I wonder if there’s maybe two aspects there from personally, there’s a way that you identify success and then maybe also to justify a design to the business?

Interviewee: So measuring success, so is that in say, a pattern which has converted really well for people or has performed really well? Yeah, I don’t know if we’re far along the road for that yet. I mean, previously I have worked for a lot of startups where you’re just in sprints all the time and you’re constantly validating so you see a little something that’s not quite right, you do a little A/B testing, you iterate on that, then you look at what’s happened, and then you iterate a bit more. But, you know, [redacted] you kind of move slow and fix things. So I don’t know if we’re at that point of closure yet. Maybe in like another 5 years or something?

Interviewer: Because I see some people talking about, most of the time it tends to be time and time taken to complete processes. But I don’t know if that is the best way to judge everything by.

Interviewee: Yeah, in our team our product owner is obligated to process success matrixes. You know, like, stats on how much our team saved and we can only do that by estimating how long does it take for someone to build a whole, we added a new brand and how long would it take someone to build that from scratch as a development team? How long would it take people to create all the design assets for that? And you quantify it outwards from there. So our department saved £10 million in 2019 and that sounds like a terrible amount of money. [inaudible] 100% quantitative, but I think it’s the best that you can do. You gotta, as that design system, yeah, justify your existence. Nathan Curtis, I don’t know if you’ve ever read any of his stuff on medium?

Interviewer: Who was that sorry?

Interviewee: Nathan Curtis, ever heard of him? He does some great stuff on Design Systems and how to quantify things and measure things. He writes some good blog posts.

Interviewer: That sounds really useful, thank you. Next question, how do you ensure the interfaces you design are accessible? I think you touched on that earlier.

Interviewee: As [redacted] we comply to WCAG 2.1 AA standard. So it’s easy to measure against that from a design perspective, you have a list of criteria that your design has to meet. And then, obviously once something is coded it’s very easy to run something like AXE or an accessibility checker on it and check. The difficulty with, you know, all the individual components is that you can have a load of accessibility tested, accessible components, but they can still be used in a way that isn’t accessible. Strangely enough, Nathan Curtis has another blog post on this, read his work!

Interviewee: If you’re looking at a whole user journey, rather than just individual components - a lot of it is to do with copy and is the page semantically structured correctly and you know, so, a lot of these things are journey specific, rather than individual component specific. So, you know, you can still plug in all our components and then use them in a way to create a journey that is not accessible, so we always advise teams to test their own journeys rather than just assuming because you know, our code ticks all the boxes, that their journeys will too.

Interviewer: So do you have some documentation that goes alongside your design system and explains…

Interviewee: Yes, we have a website that kind of pulls everything together, we have some UX and copy guidance, we also have accessibility guidance. I’ve just been working on it with our content designer, trying to get it into a bit more shape. It’s nice to sort of think about everything and document it.

Interviewer: Cool, thank you. What do you see being the biggest opportunities or challenges for accessibility in the future?

Interviewee: I think there’s sort of a, it’s like anything, a business need and then the customer needs. I mean a lot of our sort of, [redacted] principles are around building the best [redacted] for customers. I’m always reminding people of that, because the [redacted] for a product owner is trying to flog you loans or a mortgage. You know, their objectives are for more people to click this button and to go through and convert on this journey, rather than, we want people to make the right choices for their finances and that will make you more prosperous. So there’s always going to be that business vs customer need. So that’s a huge challenge.

Interviewee: But I think, as you know, the web progresses and gets a bit older and people are becoming more and more aware, you know, the need for accessibility, I also think that these, sort of, really high profile lawsuits, things like dominos went through one recently and Walmart, I think. There’s been a few of them that have come through in the states where you know, if anything you can say, you know, people can take us to court if they can’t access our product. That works more on a business need than it does on. Also another one I’m going on about is search engine optimisation. If your code’s accessible and it’s really clean and it’s well structured then search engines are going to find your content and that always appeals to product owners and business people so that’s another nice plus point for accessibility.

Interviewer: Yes, because one of the things that’s so horrible about the Domino’s case is that they kind of thought that, the money they would have to spend to make it accessible didn’t outweigh having to make it accessible. It’s really evil and horrible capitalism.

Interviewee: Well I mean grand perception is really important these days and you’ve got to be seen doing well by your customers otherwise people aren’t going to like you and then hopefully won’t use you. The ultimate irony with the dominos, final, this is what happened page that they put on their Internet, used a really light grey background, which you couldn’t read. It’s just like, “have you not learned anything?”.

Interviewer: Oh no, that’s terrible!

Interviewee: At least turn the contrast around and use a darker background.

Interviewer: Wow. Ok, so I think that’s pretty much all my questions, we’ve gone through them pretty quick. I was just wondering if you think that there’s anything that you think I’ve missed, that would be useful to know, or…?

Interviewee: Just trying to think about it… I guess, our components get tested by sort of, this kind of big organisations now that specialise in accessibility testing that’d be worth having a look at, if you haven’t already, There’s one called the Digital Accessibility Centre and they’re a fantastic organisation and they employ people with lots of different disabilities and with different needs. I’ve been up there to visit a couple of times, to watch them testing our components and learn from that and um, yeah really great organisation, really good hearted. It’s a lovely place to visit and a really nice day - it gives you warm fuzzies.

Interviewee: Another one we use is ability net, they’re more kind of, consultant based so they came and sat in house with us for a couple of weeks and they’re very knowledgeable and they’re more business focused than on the cuddly site. So, yeah, I’m trying to think what else in terms of accessibility that we’ve been doing that’s worth mentioning. I can’t really think of anything, but if there is I’ll feed it through to you. What is your actual research question? What are you looking for some ammunition on?

Interviewer: Let me look up my actual research question, because I can’t remember it off the top of my head. The one I’ve come up with at the minute was, “When compared to traditional static websites, how can users independently personalise the user interface of websites to positively affect accessibility?” So it’s very wordy at the minute.

Interviewee: So ways that individuals can personalise a website, to make the experience better for them. I guess you’ve got some, sort of, WCAG criteria around that, like you need to be able to, you know your CSS needs to be in a state that users can override it with their own stylesheet if they want to. Things like, I know, there’s stuff that we’ve done with the national autistic society and also designing for people with dyslexia. I think, there was something there on allowing people to put a higher line spacing on things, there’s no sort of, WCAG ruling on things like font sizes and line height, but your user needs to be able to, I think, expand it to 1.5line spacing and 2 times paragraph spacing, or something along that. I can send you all this boring WCAG stuff, if that would be useful? So yeah, they would help you to personalise your website. Let me have a rummage through this stuff I’ve got and see if I’ve got anything to support that.

Interviewer: That’d be great, that’d be really useful. Because I think that one of the things I was thinking about was not just WCAG guidelines, but the gov.uk put out some posters about different accessibility issues and how you can cater to them. Some of them aren’t necessarily included in the WCAG guidelines, so I thought that maybe it’d be interesting to look at doing something that would help with those as well. So it’s all really useful, so thank you.

Interviewee: I think the difficulty with WCAG is the irony in it. For something that’s supposed to be able to help make the web easier to use, it’s totally not accessible to anyone in terms of a human reading some words and understanding what it all means. I just, you know, when I first started with it, I went through and read everything and then wrote it all out in my own words because it’s sort of unfathomable and it’s like a legal document. There is a, let me dig it out, there’s a couple of links I’ve found recently where people have actually gone through and rewritten it in a human language. So that might be worth forwarding on, I’ll send you that as well.

Interviewer: That’s brilliant, thank you. Thank you very much for your time again, I really appreciate it and I really enjoyed speaking to you as well!

7.7 - Developer Interviews: EFWD Transcript #

This interview was conducted by email.

Interviewer: What do you do in your day-to-day role? What are some of the main aspects of the role?

Interviewee: I’m an educator and freelance web designer. Most of my role consists of content writing and production. I also work with clients to help them push their startups beyond the initial phase with design system work.
Interviewer: What excites you about your work?

Interviewee: The most exciting thing about working on the web is reach and inclusivity. Almost anyone can publish something on the web, which makes it an incredibly important, powerful network of ideas.

Interviewer: What are the most challenging aspects of designing accessible and user friendly interfaces that you’ve worked on? Why?

Interviewee: It very much depends on context. On greenfield projects, there’s little to no barrier. On some projects—namely ones that have a heavy JavaScript stack, there are lots of inherited accessibility issues that overcrowd any positive new elements. It’s a tough balance.

Interviewer: When thinking about designing and implementing a new UI component or feature, do you have a process for doing so?

Interviewee: yep!

Interviewee: 1. Sketch it out on a notepad
Interviewee: 2. Sketch out any user-flows
Interviewee: 3. Prototype with HTML, CSS and JS
Interviewee: 4. Test the prototype with screen readers, input devices etc.
Interviewee: 5. High fidelity design and build
Interviewee: 6. Repeat step 4

Interviewer: When working on user interfaces, how do you evaluate the success of a design?

Interviewee: Success of the design I do is 100% based on the goals set at the start of the project. If it achieves all of those goals, it’s a success. If not, there’s still plenty to do. So to answer your question, it depends ;)

Interviewer: How do you ensure that the websites you design are accessible?

Interviewee: A combination of manual and automated testing. Automated tools including tota11y, AXE and continuous integration. Manual testing includes various input devices and screen readers such as VoiceOver and NVDA.

Interviewer: What do you see being the biggest opportunities or challenges for accessibility in the future in the field?

Interviewee: Culture is probably the biggest challenge. Unfortunately, design and development is heavily orientated towards able people and I don’t see that changing. A seriously big opportunity would be someone breaking through that culture and changing things across the board. I think cases like the Domino’s legal challenge could help pave the way, but realistically, unless design and development culture changes wholesale, accessibility will continue to be undervalued.

7.8 - Study 1: Bog Roll Business Builder interactive website questions #

1. How big should the font on your e-commerce site be? (Ensure that you can easily read it!)

• Small
• Medium
• Large
• Larger
• I'm not fussed

2. How should additional product information be displayed? (Ensure that you easily understand it!)

• Paragraphs of text
• Bullet points
• A mixture of text and bullet points
• Content displayed in a collapsible container
• I'm not fussed

3. How should product options be displayed?

• Dropdown list
• Row of cards
• Radio buttons
• List of cards
• I'm not fussed

4. Where should the product image sit in your site's listings?

• Right of the text
• Left of the text
• Below the text
• Above the text
• I'm not fussed

5. Where should the 'Add to basket' buttons sit?

• At the start of the text
• Midway through the text
• At the bottom of the text
• I'm not fussed

6. What kind of colour scheme should we use?

• Light theme
• Dark theme
• High contrast theme
• Low contrast theme
• I'm not fussed

7. How should reviews of the product be displayed?

• Blockquotes
• Collapsible section
• Visual indicator
• No reviews
• I'm not fussed

8. What size should the spacing be between elements?

• Small
• Medium
• Large
• Larger
• I'm not fussed

9. Which of these additional features adds the most value for a user?

• View counter
• Number sold
• Additional process information
• I'm not fussed

7.9 - Study 1: Google Form survey questions #

What is your unique ID as provided on the website?
Please rank the following statements from 1 to 5, based on how much you agree with them following your experience.

1. My completed design is easy to use

2. My completed design meets my own personal needs

3. I am satisfied with my design

4. It did not take long to complete my design

5. The readability of my design is very important to me

6. The layout of my design is very important to me

7. The ease of use of my design is very important to me

8. The accessibility of my design is very important to me

9. What's your favourite part about the design you created?

• The readability of the design
• The aesthetics of the design
• The layout of the design
• The ease of use of the design
• The ability to easily access additional information
• Easy to click items
• Other

10. How do you think that design you created could be improved?

• Increased readability of the design
• Increased aesthetics of the design
• Improved layout of the design
• Improved ease of use
• Easier to access information through alternative methods
• Easier to click items
• Other

11. Can you provide a bit more information as to why you chose the options used in the design you created?

12. Do you think that the design you created meets your own needs? If so, how?

13. Which were the most difficult options to choose between?

14. How often do you use online shopping websites?

• More than once a day
• Once a day
• Once a week
• 1-2 times a month
• Rarely or never

15. What types of products do you purchase online the most frequently? (Maximum of 3 answers)

• Books
• Clothing
• DIY and crafting equipment
• Entertainment (Films, Video games)
• Food & grocery
• Health & beauty
• Homeware
• Toys and games
• Sports
• Other

16. What type of online shopping websites do you use the most? (Maximum of 3 answers)

• Auction sites (e.g. eBay)
• Book shops (e.g. Waterstones, WHSmiths, Amazon)
• Clothing (e.g. H&M, Nike, ASOS)
• Department stores (e.g. Debenhams, John Lewis)
• DIY and crafting (e.g. B&Q, Home Depot, Hobbycraft)
• Electronics (e.g. Currys, PC World, Amazon)
• Entertainment (e.g. Steam, Amazon)
• Food & grocery (e.g. ASDA, Deliveroo, Whole Foods)
• Homeware/Furniture (e.g. IKEA, MADE, Wayfair)
• Marketplaces (e.g. Amazon, Etsy, eBay)
• Music (e.g. Amazon, HMV)
• Sporting goods (e.g. Adidas, Puma, ASICS)
• Other

17. Personally, what do you think are key features of a website that provides a good online shopping experience? (Maximum of 3 answers)

• Quick to purchase products
• Easy to search for products
• Easy to read information
• Aesthetically pleasing design
• Consistent and easy to understand design
• Accessible to all users
• Provide different ways of getting information (through additional images, video or audio)

18. Which of these issues do you think contribute the most to a poor online shopping experience? (Maximum of 3 answers)

• Lengthy process to purchase products
• Difficulty searching for products
• Difficult to identify key information
• Poor aesthetics
• Inconsistent and difficult to understand design
• Inaccessible to all users
• Lacking easy ways to get additional information
• Other

19. Do you identify as having a disability?

• Yes
• No
• Prefer not to say

20. What is your disability?

21. When browsing websites and online shopping, what are your specific accessibility needs?

22. What, if any, assistive technologies do you use when browsing websites and online shopping?

23. How would you describe your gender?

• Female
• Male
• Non-binary
• Prefer not to say
• Not listed

24. What is your age

• 18-29 years
• 30-39 years
• 40-49 years
• 50-59 years
• 60-69 years
• 70+ years

25. Which country do you live in?

26. Please select from the options below as to how you can be contacted.

• I would like to be contacted in regards to the Amazon prize draw.
• I am happy to be contacted about the design I created and the research project.
• I would like to be informed about the outcomes from this project.

7.10 - Study 1: Participants’ disabilities and access needs #

Below are short summaries of the disabilities and access needs provided by participants within the secure Google Form at the end of the Bog Roll Business Builder interactive website.

• Blind. Participant uses the NVDA screen reader to interact with websites.
• Visually Impaired. Participant uses ZoomText software to interact with websites.
• Dyslexia. The participant needs to be able to easily understand information and as such, inserts specific CSS to make reading selected content easier.
• Motor impairment and hearing loss. The participant requires captions and transcripts when interacting with content on the web.
• Severe short sightedness and dyspraxia. The participant requires clear text and larger fonts when using the web and uses browsers' zoom features to achieve this.
• Ehlers-Danlos syndrome with Postural tachycardia syndrome, Chronic fatigue syndrome and Fibromyalgia. The participant requires larger text and content provided in a variety of different formats when using the web.
• Chronic pain, fatigue and fibromyalgia. Participant requires high contrast content which is easy to read with more spaced out text when using websites.
• Low vision. Participant uses Magnifier and sometimes Narrator to help them browse the web. Additionally, they require a large text cursor in a colour which is easy to identify.
• Mental health disability. Participant did not answer as having specific access needs when browsing the web.
• Deafness and Retinitis Pigmentosa. Participant uses the NVDA screen reader and Talkback and requires that websites are keyboard accessible, laid out in a clear and easy to understand manner.
• Low vision, amongst others. Participant uses custom CSS to increase text size and spacing. Participant also requires good contrast between content.
• Visually impaired. Participant uses a screen reader, the browser's zoom capabilities and makes use of an increased contrast and read aloud extension in their browser. Additionally, the participant browses in a 800 x 600 resolution.

7.11 - Study 2: Fast fashion websites analysed #

A list of the 10 fast fashion websites that were analysed before designing the Miss Thread website.

• ASOS - <asos.com/women>
• boohoo - <boohoo.com>
• Missguided - <missguided.co.uk>
• Misspap - <misspap.com>
• Missy Empire - <missyempire.com>
• Nasty Gal - <nastygal.com>
• Pink Boutique - <pinkboutique.co.uk>
• PrettyLittleThing - <prettylittlething.com>
• SilkFred - <silkfred.com>
• Quiz - <quizclothing.co.uk>

7.12 - Study 2: Full list of Global personalisation options #

Additional skip links #

Would you like additional skip links to be displayed on pages where relevant?

• Show additional skip links
• Hide additional skip links

Adverts #

Would you like adverts to be shown or hidden?

• Show adverts
• Hide adverts

Color theme #

Which colour theme would you like to use?

• Light
• Dark
• High contrast

Detailed section descriptions #

Would you like section labels and headings to provide further description?

• Provide additional descriptions
• Hide additional descriptions

Letter spacing #

How big do you want the spacing between letters to be?

• Small
• Medium
• Large
• Extra large

Line height #

How big do you want the line height to be?

• Small
• Medium
• Large
• Extra large

Page summary #

Would you like a summary of the page's content to be displayed at the top of the page?

• Show summary
• Hide summary

Size of spacing between items #

How big do you want the spacing between items to be?

• Small
• Medium
• Large
• Extra large

Text size #

• How big do you want the text to be?
• Small
• Medium
• Large
• Extra large

Word spacing #

How big do you want the spacing between words to be?

• Small
• Medium
• Large
• Extra large

7.13 - Study 2: Full list of Local personalisation options #

Font size #

Select the text size you'd like

• Small
• Medium
• Large
• Extra large

Letter spacing #

Select the letter spacing size you'd like

• Small
• Medium
• Large
• Extra large

Word spacing #

Select the word spacing size you'd like

• Small
• Medium
• Large
• Extra large

Line height #

Select the line height you'd like

• Small
• Medium
• Large
• Extra large

Line length #

Select the line length you'd like

• 60 characters
• 80 characters
• 50%
• 100%

Detailed description #

Would you like additional description for this section?

• Provide additional description
• Hide additional description

Additional information format #

Which format would you prefer the additional information to appear in?

• Paragraphs of text
• Bullet points

7.14 - Study 2: Demonstration video shown to developers and transcript #

This video can be found on YouTube, provided with captions which have been listed below. The video was uploaded 6th December 2020 and is unlisted.

Miss Thread Developer Interviews

So this video is going to be showing what I showed developers during the developer interviews. At the minute on screen I've got the Miss Thread website on and I'm scrolling through the home page passing through some of the the images and the fresh threads section at the minute and scrolling towards the footer on the page. I'm clicking on the... well I'm hovering over the change style of this site. Then I click on it and I'm now taken to the change the style of this site page. I've scrolled down the page showing the section where there's additional skip links, adverts and the rest of the global personalizations that the user can make. On screen I'm clicking on some of the options: I've changed the color theme to be dark, high contrast, then back to dark. I'm clicking over the detailed section descriptions and I've selected ‘provide additional descriptions'. I'm just going through and showing to the developer all these different options and how they take effect. As I'm clicking on the options the example content on the left is updating automatically, but really it is as soon as the user selects an option on the right, the design on the left is updating to show to the user, and the developers in this case, how exactly those personalizations take effect. I've made a few different personalizations now, the word spacing is spread out, the line spacing has changed. I've navigated back to the home page and I'm just showing to the developer how the personalizations have taken effect across the site. So all of the wording's changed, the line height has changed across the site. I'm now navigating to the clothing page. I've scrolled down and I've selected the mustard ruffle cozy joggers and I'm looking at the individual page for that product now. I can still see all my global personalizations have taken effect and there's a lot more text on the purchase button and now I've hovered over the line of text that says this item costs 35 pounds and I've clicked on the button that says 'change this styling' that's appeared. I'm now going through changing the line length to be fifty percent and I've changed the size of the text as well. I've done the same, I've hovered over the additional information clicked on 'change the styling' and I've changed the additional information format to be bullet points, then changed it back to paragraphs of text. Finally I'm hovering over the title for this page which is the mustard ruffled cozy joggers title and I've changed the font size of that just to display that these changes could be made in any order. I've then scrolled down to the bottom of the page, turned off the personalization popups just so that the 'customize this item' pop-up doesn't display and then finally I've highlighted how the personalizations can be removed by clearing all the changes on the site.

I'm now showing the developers within my code editing software how the CSS is structured, so on screen at the minute there's groups of different CSS custom properties. I've highlighted all the ones associated with color so there's things like primary color light, primary, dark another section for high contrast colors and it just shows how these values are abstracted in the code. I'm now showing how global CSS styles are implemented and I've got them within a separate folder so for the color theme for example: the way I apply them is that I've got a class called color theme and I'm using Sass here or Scss to write this code and after color theme I've got a light variant, a dark variant and a high contrast variant and whenever this class is applied to the HTML I'm then targeting the body and updating the CSS custom properties. So within this code, there's the first section which relates to the light theme and within there I switch color primary, color property to be whatever the primary color light variable is, the same for the secondary color that's being set to secondary color light and so on and so forth for color background, alternate background, color text, UI active, button colors and the same is being done for each different personalization option so in this example on screen, we can see the light dark and high contrast color themes.

On screen I'm moving my mouse over the different sections and in the interviews i was explaining just that.

Now on screen there's an example of a local personalization and on screen there's a CSS selector that's targeting the line height and the class is u-line-height so I tried to put the u at the start of the selectors so that when I'm looking at HTML and local personalization has been made, I've done it with a utility class which is described in this thesis and for each variant that the user can select between, so for line height it has small, medium, large and extra large. On screen at the minute there's four different rules so there's one targeting small and that sets the line height to be 1; there's one for medium which is 1.2; large 1.5 and extra large where the line height is set to 2. For each of these rules because it's a utility class and I know that I definitely want this style to be applied to the design of the site this rule is reinforced with the !important property which overrides the specificity of the existing CSS to ensure that these rules are applied. So yeah, that's the kind of thing shown on screen at the minute and it just illustrates how these local personalizations were made.

Now on screen I've gone back to the browser and the top half of the screen has again, that global personalization page, and I'm within the site about to change the color theme of the site. The bottom half of the screen contains the development tools within Google Chrome, sorry, within Firefox and on screen at the minute I've got the storage application window open and specifically I'm showing the local storage for the Miss Thread site. As I select the dark color theme, on screen you can see that within the local storage a value is stored along with a key relating to the color theme. So on screen as I selected the dark color theme you could see that a key called p-colorTheme popped into the local storage and the value is colorTheme--dark and that's just showing to the developers how I was storing the different personalization options. So I'm storing these changes within local storage and by looking for the key and using the value, then whenever the user closes their browser and reopens it on the site I can apply those personalizations again

I'm doing the same and showing how it works similarly for line height. I've selected a medium line height and this can be seen in local storage now there's a key p-lineHeight that's appeared on screen and alongside it the corresponding value is lineHeight--large.

I've selected extra large, the key p-lineHeight now has a value of lineHeight--xLarge.

I'm clicking through some of the global personalization options on screen again, this time I'm looking at the size of spacing between items again another key in local storage has appeared p-spaceSize and alongside a value of medium. I've changed it to be large then extra large and as you'd expect, this is also updated within the local storage that's being shown in the developer tools.

I'm navigating again now to the cozy ruffled joggers on the site. So I navigated to the clothing page and now I'm on the specific page that relates to the mustard ruffled joggers. At the bottom of the screen I've still got the developer tools open showing the local storage. On the website I've opened up the 'change the styling' menu that relates to the heading: 'mustard ruffled cozy joggers'. So I've clicked on 'change this styling' to change the styling for that specific element, these are the local personalizations now and I've selected font size and I've applied a large font size to it; so that's a local personalization I've made to the heading for the page. Now as soon as I selected that large text size on screen it shows that there's a new key that's appeared in the local storage. This key is a bit longer so it relates to, sort of, the local personalization and what's captured within the the local storage key is, kind of like a, a JavaScript or CSS selector that's going to allow me to specifically target that element that's been personalized again. So the key in this case is pi-h1 with an id of product-name-holder with a class of js-personalizeThis--textSize, so it's quite a long key but I can then use that selector to actually target that element and I can check for that on each page the user goes on, so if this element is found with on other pages that same personalization can be made again, just to ensure that the user has a consistent experience and alongside this key I'm storing a value similarly to how I did for the global personalizations, but alongside this key I'm storing the value of u-textSize--large and that value actually relates to the utility class and just, all that happens when that key is found, when that selector is found, I just apply that utility class to it.

On screen now I am closing the font size and I'm looking at the letter spacing for the for the header and I've changed the letter spacing for this header to be medium, again within the local storage panel I have a similar key, so it's p-h1 with an id of product-name-holder a class of js-personalizeThis--letterSpacing to specify that I'm looking at the letter spacing now for this element. Alongside it there's a value of u-letterSpacing--medium which again relates the utility class that would be used to provide this local customization.

I've closed the 'change the styling' menu and again I'm back into the code now and I'm illustrating on screen how that drop-down menu can be included within the website. So open in my code editor I have the file, product-display.njk, so this is a nunjucks file and that's just a templating language for HTML and on screen there's a lot of HTML and it just relates to the individual product page so scanning through the code you can see things such as a list that relates to the collection that this item is, the color, the material, the model's height and the 'our thoughts' section. At the top of the screen at the minute there's a h2 for page summary, so this page... this file is just describing the elements that are on the individual product page. On screen at the minute I've highlighted a single line of code, it's line 51 within the product display file and it's a Nunjucks include, so it says include and then a file is listed which is: 'partials/customisation-dropdown.html', what that does is it will include that file that's been specified and within customization drop down is the menu and the semantic HTML that displays that 'customize this element' drop down that appears when a user hovers over a specific element on a product page, allowing them to do the local customizations and in the developer interviews I was using this just to highlight how this could be done as part of the build process or during the development process they could just include, sort of a standard file, that would include all the localized personalizations and they could just include a single line to do it, it wouldn't be a lot of work to get that in there.

I think that's it, I'm clicking around around the line just to illustrate it and sort of one other thing that I should mention is above that 'include' line I've got another Nunjucks line which is line 50 in the 'product-display' file where I'm setting a variable, in this case it's a variable called target element, I'm setting it to be the selector that I want to use to target that individual element. So in this case I've set target element to be a string which is targeting an ID of product information and within that a div element that has a class of js-personaliseThis and this allows the developer to specify exactly the element that they want to be targeting and this is passed into the customization drop down so that all the styles in there can be applied to specifically that element that's targeted with the selector that developers just passed in. So yeah, that's everything.

7.15 - Study 2: Interview questions #

1. Based on the quick video that you've seen and considering that for each feature you would have to have:

• Multiple design tokens (for example: small, medium, large and extra large spacing)
• Specify which elements of the user interface you would allow to be individually personalised
• The current structure and design of the design systems you work with

How big of a project do you think it would be to adopt this method of personalisation with your design system in a similar way?

2. Given the current testing that you conduct on the user-interface (accessibility testing, usability testing), how do you think using personalisation would affect your testing?

3. Typically, when thinking about website design, there's a balance between branding/marketing and usability. Personalisation could change the look and feel of a website quite dramatically. In your experience, how do you think branding/marketing teams would react to it?

4. Elizabeth Churchill, Director of UX at Google, wrote that "implementing or adopting a design system not only reduces decision making for individuals but also reduces cognitive load for teams". I think that off the back of this, designing and maintaining design systems can be quite involved, different stakeholders have different needs and want different features. In your opinion, how do you think personalisation would affect those processes? Could you foresee the design and maintenance being any easier or more difficult as a result?

5. How do you think that personalisation would affect developers within your organisation that use the design system within different products?

6. Finally, is there anything I've missed? General thoughts or feedback about the prototype that we haven't covered so far?

7.16 - Study 2: Description for the codes #

Below are descriptions for the codes that were used when analysing the developer interviews.

Design and maintenance challenges

• These challenges will stem from any problems or issues that are identified during interviews, regarding designing and maintaining systems with personalisation.
• This will be recognised when participants have any concerns or provide feedback about the design and maintenance with the prototype in mind. This may also be revealed when participants reveal the way that current systems differ from the prototype.
  This code is generic, as to capture as many of these challenges as possible. If there are any challenges that can be foreseen, regardless of whether they relate to communications, implementation or support, these need to be captured and addressed.
• An example of this would be a participant who has identified that the varying styles implemented with personalisation would need to be clearly communicated.

Developer use

• This code will relate directly to the developer experience. As identified in section 3.4 developers are required to develop products faster and faster and as such, personalisation must not dramatically increase the developers' workload.
• This code will be recognised following the question where participants are asked for their thoughts regarding developer use of a design system with personalisation. It may also be apparent when developers discuss maintenance of existing systems.
• This will relate specifically to developers who are not in the participants’ immediate department but still use the design system. This is to focus on any existing problems with communication and maintenance and to identify how these can be resolved going forwards.
• In context, this may reveal insights such as the way that documentation around personalisation should be implemented based on existing experience with external developer use of design systems.

Testing

• Testing will cover any mentions of accessibility, usability, visual regression or validation testing that participants mention during interviews.
• This code will be identified when participants raise any of the methods of testing or are discussing methods of validating the work.
• As with the ‘design and maintenance challenges’ code, this code is generic as to understand the different methods of testing that participants would want to use. These methods can then be captured and compiled into a shared, best practices plan for testing of systems with personalisation enabled.
• For example, this could be a suggestion from a participant who explains that they would want to conduct visual regression testing on the different personalisation options to ensure that they do not visually break the layout of the existing design.

Visual changes

• ‘Visual changes’ will relate to the opinions of participants on the different personalisation options and how they feel it would sit with designers and branding colleagues.
• It should be recognised when participants answer about brand guidelines and the changing visual design.
• This code will explicitly relate to opinions on the attitudes of designers and branding teams on personalisation and not to aspects of the interviews such as visual regression testing, which will be covered under the code, ‘testing’.
• An example of this would be where a colleague shares a concern that their branding team may not favour a variety of different options and as such, would have to be involved from the start of the project to involve these different options.

Workload to integrate

• Excerpts coded as ‘workload to integrate’ will be linked to the participants' opinions on how much work they believe would be involved with implementing personalisation into their existing design systems.
• This should be identified when participants talk about the ease or difficulty of implementation and their thoughts on any timescales or workloads as a result of this.
• This topic will relate to implementation but will also cover any mention of testing or validation as a result of the implementation. However, it will not include maintenance as this was not demonstrated during the interviews and would require additional work to cover properly.
• An example may be when a participant mentions that the prototype displayed would not require much additional development as their systems already use abstracted values in design tokens. As such, integration would take roughly 2-3 weeks.

7.17 - Study 2: EFWD Transcript #

[Recording did not start successfully earlier, only noticed this during the interview and before the fourth question]

Interviewer: Ok, there we go. So this next question is kind of thinking also about the earlier stages of designing it. Elizabeth Churchill, Director of UX at Google wrote:

Interviewer: Implementing or adopting a design system not only reduces decision making for individuals but also reduces cognitive load for teams.

Interviewer: So it’s sort of this idea that they don’t have to think about which button to use, they can just look in the design system.

Interviewee: For sure, agreed.

Interviewer: I was thinking, sort of designing design systems in the first place can be quite involved if you’ve got different stakeholders with different needs and they want different features with buttons or cards or whatever it is. So in your opinion, how do you think personalisation, from the start, would affect these processes? Do you think that design and maintenance of systems would be more involved, or do you think it would be any easier?

Interviewee: I think it’d be, it’d add extra work in creating a system and the thing is as well is that there’s no point in creating a design system, so a way that I often recommends to not start with a pattern library but to actually build whatever you’re building first and then create a design system out of that instead, so you use the methodologies that you know, you know, design tokens and style guides. So you use all those sort of core principles and methodologies and then once you’ve shipped what you need to ship, then the design system process follows that so you go through and create an inventory and stuff. So that would add more work to that as well, so to create a component inventory you’d have to create an inventory for each individual customisation. Saying that, when you’re building the design system itself, you’d probably implement the same tools or what you’ve created the tools you’ve created inside the design system too. So you wouldn’t have to create a variant for every look and feel, yo u could probably use this, there’s a term called ‘dog feeding’, where you use the tools that you’ve created to also test the tools that you’re using and to use them on a daily basis. So a good example, the platform that we’re talking on now Whereby, you can almost guarantee they’re using this for video chats while they;‘re working so (well I should hope so) sos that the project is working as it’s expected to and to come cup with new features and stuff. Always use your own products, never use someone else’s products when you’ve started making it.

Interviewer: Cool. Alright. The next question is kind of moving on from that last one, how do you think that personalisations would affect developers that use the design system within organisations? Do you think it’d be easier for them, to understand or a bit more complicated with personalisation involved?

Interviewee: I think the personalisation adds extra x amount of outcomes, so I think it’d be more complicated, but also, like, if you’re building that thing into a project then it becomes part of a day-to-day interaction with it, so you know, yeah, more difficult, but it’s just part of the job they’ve got to do is maintain that and then you’ve got a team full of people who are user orientated then it shouldn’t be an issue for them really because their focus is on making the best tool. So, yeah…

Interviewer: Alright, the last question is, finally, do you think there’s anything I’ve missed or have you any general thoughts or feedback about the stuff that you’ve seen and we haven’t covered so far?

Interviewee: The only thing I’d say is that when you had the, the specific, when you were doing the specific customisations, I think what would be useful is for it to say, at the bottom in the footer, you had the option to apply the not show any more pop-ups, but to also provide that option within a pop-up as well. The same for the reset as well, I just think that would be really handy because once you’ve sort of tweaked it, then it’d be useful while they’re in that cognitive space, to say “Ok, I’m done now”. But apart from that, it’s cool, it’s really cool - you’ve done a good job with it.

Interviewer: That’s really good feedback, thank you.

7.18 - Study 2: UIDL Transcript #

Interviewer: Cool, perfect, think that’s recording. So the first question is, is based on the video you’ve seen and considering for each of the things to be personalised, they would have to, you’d have to have more design tokens for example, the small, medium, large, extra large spacing tokens. Then you’d have to specify the individual elements of the UI that you could personalise and given the structure of the design system that you worth with at the minute, how big of a project do you think out would be to adopt this method of personalisation?

Interviewee: Erm, it would be more than feasible. Yeah. Um, any system already be paired with design tokens or some sort of high level styling. It’s obviously something you’d need my developer to talk to about, but in terms of how easy would it be… yeah… I think it would be quite easy to adopt. Absolutely.

Interviewer: Cool, that’s good to hear. Brill.

Interviewer: Ok, erm, and then, the next question is: So I think we spoke before, you mentioned that the components are tested by different people. So, one of them was an accessibility group who run through accessibility tests with the components? And given how with personalisation there’s lots of different options you could pick to make different designs, how do you think that this would affect the amount of testing that you would need to conduct?

Interviewee: In terms of just basic things like colour contrast and it’s a difficult one, I mean… you kind of want all of your options to be accessible. If that’s the case, there’d be loads of different variables for them to test. But then, if it’s user personalised then perhaps someone likes… you know, particular styling or a particular contrast which doesn’t necessarily a WCAG criteria. In which case, that’s gonna work for them so… I dunno in terms of extra sign-off. Yeah, it’s a funny one. Whether they’d want to assess all of the different permutations of styling, or whether that’s down to an individual user preference or you know, provided I think there’d be more interesting things like are the controls obvious, you know, do they work on a screen-reader. Yeah, is it obvious to the user it’s kind of a more of a usability than accessibility issue. Turning them on and off and assessing accessing them - is that intuitive. I guess you don’t want to get into a situation where someone’s just made it totally illegible and they have no idea how to turn it off, so I think those things need to be obvious.

Interviewer: Ok, that’s really helpful, thank you.

Interviewee: Also, we had this discussion the other day. Lots of things pass an automated test, because all of our products have to go through an automated test, so and it’s basically just against some WCAG criteria, whatever runs./ There’s a lot of things that will pass because there is an alt ta, but the lat tag might have , you know, rubbish text in it or something that doesn’t make any sense or isn’t at all meaningful in context. But because there’s alt tags there, it will pass a test, but in terms of an actual human using it, it won’t. So these things are real considerations, again, it’s more of usability than accessibility issue.

Interviewer: Cool. Alright, so, my third question is: sort of typically when thinking about web design, I think there tends to be a balance between branding and marking, and then usability on the other side because I guess like brands want to reflect their designs and make them memorable but also to spread brand awareness. So thinking about the balance between the two of them, I guess personalisation could, as we’ve discussed already, change the look and feel of a website quite dramatically. In your experience, how do you think branding and marketing teams would react to it.

Interviewee: I don’t think it would sit so well with them, you’d have to design a scheme where everything looked on brand, regardless of how you changed it. I guess you’d keep like the same base font, but you’re just increasing or decreasing a size to make it more legible. I think there’s kind, this tool needs to be much more about making it more legible than making it pretty or, you know, look different or visually… I guess to make it look visually different in a way that will help your user not in a way just to decorate. I guess, I think that brand would have a real issue in most places I’ve worked. They would have to be involved in customising it, or seeing all of the permutations of it to be able to establish that it still looked like an on-brand product.

Interviewer: Brill.

Interviewee: That’s really great that you’re thinking about that though.

Interviewer: Oh, thank you. I thought “it’s not going to be that easy to get it implemented”, you know I thought there will be, you can imagine certain brands wouldn’t want their brands affected at all. If it’s more usable and readable and the design is changed, I thought people might push back about it. So… yeah. Apologies, the next question is a little bit wordy. But, Elizabeth Churchill, Director of UX at Google wrote:

Interviewer: Implementing or adopting a design system not only reduces decision making for individuals but also reduces cognitive load for teams.

Interviewer: I thought that was interesting but also off the back of it, I think that design and maintaining design systems can be quite involved because when doing so, different stakeholders come in and have different needs and wants for the products they’re designing. Sorry, the products they’re implementing. In your opinion, how do you think personalisation would affect the processes of designing and maintaining design systems. Could you foresee design and maintenance being made any easier or more difficult as a result.

Interviewee: It’s a difficult one, I guess with our design system, we try and lockdown as much as possible. The whole point of a design system is bringing consistency, that’s our main aim. At [redacted] we have a very fragmented digital estate, across lots of different brands and the main aim of the system is to bring consistency. Then take all of those little design decisions away from teams. So they don’t have to all argue about what colour a button is, they can put their time into making products that work for our customers. I guess it does add complexity if with a tool like this you’d have to be really thought through the different variations because you wouldn’t want a designer to say… I guess you need a base kit of styles so you can show how the site usually looks and perhaps everything else is sort of looked at in isolation or differently, because you would for me, I try and lock everything down as much as possible especially in terms of colour and font use because otherwise you know, something that’s in the hands of a designer that’s been carefully crafted will come out looking beautiful, but you know, our design system is vast and used by a lot of people who aren’t designers and letting them make decisions with this vast colour palette will end up with some absolute horrors. So, I think we’d need to have a very considered approach to it. I mean, giving, making a kind of palette where everything worked together would certainly help, rather than a load of random colours.

Interviewee: You’re really making me think about this, it’s great.

Interviewer: This is great, thank you.

Interviewer: So, I guess leading on from that quite nicely, how do you think personalisation would affect the developers within the organisation that currently use your design system.

Interviewee: Personalisation, so in terms of things like sizing, fonts, colours? Erm, if the sort of core build was the same and this was something completely separate, I think that’s fine. If it’s something they have to work on everywhere, I think that would be difficult. But I can see this being something that exists differently. So you’ve got all your core styling, so your sites or whatever using, spits out, and then this product is in addition to it and contains a different sort of nano-set of styles.

Interviewer: Alright, the last question I’ve got is, is there anything that you think I’ve missed that you’d like to comment on or any general thoughts of feedback on the prototype that we haven’t covered so far.

Interviewee: I guess my only thought is that, we’ve done a lot of testing with people with disabilities and people that use assistive tools and they tend to have like their own specific set ups and if you’re very low visioned, you might have everything already zoomed in and you might have all the settings all set up, so all of the text is bumped up already. I guess you;‘d need to consider how this tool would work with people who don’t use the default browser setting. That would need to be a real consideration. If it already starts off huge and it bumps it up huger, does it… yeah, I guess, trying to think of the scale of it and it could end up being enormous and they wouldn’t know where they were on the page. It’s a real edge case, but there are these people that use these mega zoom tools that zoom in onto the entire screen as like one input field, that’s a consideration. Again, it’s a really minor edge case, but it’s another assistive tool worth thinking about. And yeah, obviously screen readers, that tends to be what, in terms of accessibility, that’s sort of the tool everyone kind of defers to because if it works on a screen reader it’ll usually work everywhere else.

Interviewer: That’s great, thank you.

7.19 - Study 2: DPDM Transcript #

Interviewer: Brill, ok. So the first question is, is based on the video you’ve just seen and considering that for each feature that you’d want to personalise, you’d have to come up with the multiple properties so you’d have properties for example, the small, medium, large, extra large space options. Considering you’d have to specify which elements of the UI you’d allow the user to individually personalise and then finally, given the current structure and design of the way that the CSS, HTML and whole site works within your organisation already, how big of a project do you think it would be to adopt this method of personalisation in a similar way?

Interviewee: Erm, you might have to say the first bit again.

Interviewer: Yeah, I guess really, I’m trying to understand how big of a project is it - given that you’d have to come up and design for all these different options? Given you’d have to consider which options you’re going to allow the user to personalise and given the structure of your HTML and CSS within…

Interviewee: Yeah… so I guess… one of the first sort of things like this, like years and years ago was like you know, this like CSS multi thing of you change the contrast and you’d see some sites do it and it ended up becoming like a big, massive maintenance overhead because you’d just have to manually write all those styles up and yeah… if you changed things in like your light colour theme, you’ve also got a completely separate colour theme that you’ve got to change and if you’ve then got all these other variants that individual components, you’d end up with like… you know, hundreds of different versions of CSS files. But then, doing things we do the way we do now, where it’s all things like Sass and we’ve got things like variables and things, we’ve got things like our pattern library and you kind of know what all your individual components are and there all kind of, a lot more compartmentalised and it feels like a much more, manageable thing I think to do. Still, I think still like, a big-ish to job, more from the thinking it through I think of like, is this definitely going to work if we, like, if someone does this and this, is that gonna like, actually end up making your thing completely unreadable by mistake? But I think like, yeah, the actual, yeah… the nuts and bolts of how you’d implement it, I can, I could see that being something that we do already because we’re already doing things for like, you know… the different media queries for screen sizes and it’s just, yeah… it’s like an extra thing on top of that. Yeah, like have they selected the dark theme, or picked the, or what are larger line height versions and yeah, you can see how you’d do that and how you’d still have code that’s readable and it’s just kind of adding some variables and wrapping some blocks around things that you’ve already got rather than if like, completely separate things that you’d have to like, have from scratch and maintain and keep up to date with each other.

Interviewer: That’s great , thank you. The next question is: given the current testing that you ideally want to be conducting on the UI, so things such as accessibility testing and usability testing, how do you think using this method of personalisation would affect your testing load? Do you think it would dramatically increase it, or do you think it would reduce it in any ways?

Interviewee: I can imagine there’d be more testing for like us to do, of like yeah the kind of thing I touched on in and making sure that if we’re giving all these different options that people can combine them and that none of them are going to clash and that you’re not going to end up with that you’ve made text big but that text now no longer fits in the box that it was meant to be in and all those sorts of things. So yeah, I see like for us, maybe just having to think of those things and to build processes and things that might just automatically test that kind of thing that takes all your screenshots and compare them and just make sure that if not, change between builds and things like that. But from the end users sort of testing, I suppose it would feel like it’s, it’d be testing like a different thing anyway like a specific part of the website and it potentially means that if one person was testing it and then they personalised it a bit and then another person tested it and they personalised it a bit of a different way, then you might not be getting quite like for like things that your testing against, but it’s probably all still useful. You’d just see people using things with things configured in slightly different ways but, given like the testing we do it’s never meant to be 100% statistically valid and everything, it’s not like it’d make a massive difference. Given sort of samples and yeah… a couple of dozen doesn’t really have much of an impact on that.

Interviewer: Cool, that’s great. The next question is: typically when thinking about web design, I think there tends to be a balance between branding and marking, and then usability on the other side because I guess like brands want to reflect their products and make them memorable but also to spread brand awareness. So thinking about the balance between the two of them, I guess personalisation could, as we’ve discussed already, change the look and feel of a website quite dramatically. How do you think branding and marketing teams would react to it. Because I understand that probably some websites would want to spread their brand and have like, consistent look and feel, but yeah, it might change a bit with personalisation, so how do you think people would react?

Interviewee: Yeah, I think… I think people are kind of more open to like things looking different on different platforms anyways, so… like years and years ago, when I started, you expected things to look exactly the same on this computer and this computer and it was all stuff that was like Internet explorer does things differently and Netscape Navigator and all these ancient browsers that you’d have to like you know, you’d have to put all these hacks in to make it look ‘pixel perfect’ between like all these different browsers, but yeah as like we started to do responsive design and stuff, you kind of, people are kind of use to things being different anyway and like it’s kind of like, people are kind of accepting of the fact that it’s going to look different if I look at it on my tablet or my desktop and that some things are going to be bigger or smaller and I think now, people are getting a lot more aware of accessibility needs and legislation changes and I think if the main, kind of, thinking behind personalisation would be for someone who has an accessibility need and that they want to change these things so that they can read it better, rather than just “I want to change it because I fancy a different colour”. I think… yeah, I think people would be onboard with that, it still helps and still helps the brand even if it’s not like the same colours because the brand I think people, as well as things I was saying earlier about exactly what it looks like, I think people are more open to the fact that the brand isn’t just logos and colours, it’s more about tone of voice and experience and all sorts of values and things that go beyond just what colour something is, so I think, yeah it’s a much easier sell these days I think. I think various things contribute to it that mean, I think as long as it’s got a logo on and you still know it’s “us”, exactly what the colours are and whether things are bigger or smaller or slightly, yeah… I think it’s a much easier thing to get people on board with these days.

Interviewer: Great, that’s positive. I was a little concerned that some people might, like yeah, push back against it and say that it doesn’t conform to these guidelines.

Interviewee: Yeah, I think that with some people you might find like if first presented to it, like, they might like be like “that’s not our colours”, but then you can explain I think it’s an easier to then explain after like, yeah… people not be like seeing those colours anyways if they’re colour blind and you know, this, this means that they can read it better and buy stuff from us or whatever we want to do as our end goal, so I think it’s an easy argument to convince people.

Interviewer: Ok. This next question, this is sort of focuses more around the idea of design systems and pattern libraries and Elizabeth Churchill, Director of UX at Google wrote:

Interviewer: Implementing or adopting a design system not only reduces decision making for individuals but also reduces cognitive load for teams.

Interviewer: I think it’s the idea that if you have a pattern library or a design system, you don’t have to think about, “Oh what should this button be like?”, you can just go and look at it. But I think also, off the back of that, that designing and maintaining pattern libraries and design systems, initially, can be quite involved because you have a lot of different stakeholders with different needs for different products. So I don’t know if it’s as easy as that and that straight forward because you have to design simple features that meet everybody’s needs. So in your opinion, how do you think personalisation would affect the design and maintenance processes of pattern libraries and design systems. Do you think it would be considerably more involved and there’d be more discussions about how things, with these different options, should look? Or do you think it would be any easier?

Interviewee: Erm, so I think that it’s, IU think that with us and how our pattern library works and things like that, I think we’ve got to a stage where we’ve got something that’s pretty decent for like static web content, but the thing we’re finding more is that developers building more complicated systems are using it more now and we’re finding there’s slight gaps in it and there’s things that it doesn’t do and as well there’s things where we’ve got like the individual components, but not really, I don’t think we have the design system bit that kind of, articulates you know, if you’re using this button and this thing, then you should put them together in this way. We’ve kind of got, we’ve got these components, but then people can put them together in strange ways that wouldn’t have been the way that we would have used them, but yeah… I think as more people start using them and it gets more widely adopted, you kind of get things that on the surface look more consistent because, like yeah, we’re all using the same style of buttons, but then one team kind of interprets it slightly differently and then you end up with lots of things where we see something else and we say, “Oh yeah, we wouldn’t quite have done it like that”, but it’s because we don’t have that thing in that goes with the buttons for example that would say like, “If you’re doing x, then use them this way. If you’re doing y, use them this way.” So I think any kind of personalisation options and I think adds another dimension to like the ways that things could get used in the way that we didn’t quite intend them to be, because if we’ve kind of thought “Hey, are these, these components will always be combined together, so it’s fine” and then when someone personalises them in whatever way, that x happens to them and we know that, but then someone else might stick a different component in and put them inside another component that we haven’t kind of imagined that combination of, and then maybe then that might be a case where things being personalised and changed, might be more kind of, scope for things clashing and not like working together I think.

Interviewer: No, definitely.

Interviewee: Yeah, that’s definitely the thing we’re finding we miss at the moment, where like this… I often talk about it as like Lego bricks of like we’ve got all these Lego bricks, but we’ve not really, kind of, defined the overall Lego bricks of like, is it space Lego, or medieval Lego, it’s like, yeah, people are just kind of putting them all together to make all sorts of cool, cool things, but that you know shouldn’t be together.

Interviewer: It‘s interesting as well, you said about putting things inside other things, because within the prototype you saw, I think it was quite simple and there were individual components, but yeah, nothing inside anything else. That’d be interesting how that would work.

Interviewee: Yeah, the one we often find is like we’ve got like a tab component or an accordion component and then someone always wants to put another thing inside it and it’s like, well like, yeah, technically you can put an accordion in a tab, but don’t. But there’s nothing that stops people doing that because it’s, you take the code for one and put inside the div for another, then you’ve got an accordion inside your tabs or tabs inside your accordion.

Interviewer: Oh no. Alright, the fifth question is, yeah, kind of following on from that, how do you think personalisation would affect the way that developers within your organisation already use your pattern library. So yeah, I guess maybe it’d increase support, do you think that’d be a problem? Do you think it would cause you to have to produce more of a design system and documentation around the use?

Interviewee: Yeah, I think that there’s… I think yeah, some of it would be design systems documentation type stuff and I think more just around the processes that people follow when developing and there’s some teams that are really good and it’s all in git and there’ll be like pull requests when they’re thinking of adding something and they’ll tag my team in to review it and so we’re seeing it and it’s all part of the actual development process and there’s that record there if anyone wants to look back and go, “Why did we do this, why have we added this in this way?”, you’ve kind of got that all there but then it’s not like a standard way for the whole organisation to be working, it’s very much like… yeah. Some teams do stuff in GitHub that way and then other teams might be not even in any kind of versioning control at all or just, you know, they’re doing version control but it’s just one person doing it and it’s not, never any input from other people. So it’s kind of, probably, there’s stuff to do anyway around sharing good practice of like, how we should be building stuff and I think that a lot of the things, just like everyone having access to Slack so that it’s easier to have these conversations between teams because there’s like in the organisation I imagine and as with other big companies, there’s development happening all sorts of pockets of the organisation and there’s like IT that are kind of where lots of developers sit and my team in communications, but then there’ll be people all over the place and academic departments and support departments doing things and various levels of different capacities just playing around a bit. So I think, yeah, a lot of it is about, some stuff about documenting things and how we intend them to work, but then lots of it is just about that there’s kind of a community around it as well. This kind of underlying thing and it’s not just the thing that marketing have done and written documentation for, it’s like the thing that everyone owns and contributes to and understands why we do things the way we do. Yeah, conversations happen around people using it and if people do find things not working in the way that they expected, that they talk to us about it rather than putting in their own fixes and things like that which is what often happens as well. The more that everyone is talking to each other and the more that this stuff is out in the open, I think that the better things will be working and looks like the better the direction is going.

Interviewer: Cool, brilliant. Finally, the last question now, is there anything that you think I’ve missed that you’d like to comment on or any general thoughts or feedback on the prototype that we haven’t covered so far.

Interviewee: Erm, the only thing which was just from the very, very first screen where you were showing it. It was, I think, having it right at the bottom just makes it a bit hidden and not that discoverable and like we’ve done things with, because we’ve been doing accessibility stuff and accessibility statements and things where you press tab and that gets you to the skip to content links, but it also gets you to the accessibility options, so if you… yeah, as soon as someone presses tab, which they may well do if they’re on a screen reader or something, then they get put there as the first set of options, but it’s kind of hidden unless you need it but you get to it quickly if you do need it. Yeah, you see that on quite a few sites, I think that we just copied it off the BBC basically, that you start pressing tab and you get to the accessibility options straight away so it makes you just a bit more visible.

Interviewer: Ah, makes sense. Ok, well that’s everything. Again, thank you so much for your help, it’s been really, really interesting.

7.20 - Developer Interviews - Email Consent Form #

Department of Theatre, Film, Television and Interactive Media - Ethics Committee #

Participant Consent Form

Thank you for your interest in this project. This research activity will be used to understand how website developers try to develop accessible websites and their methods for doing so as part of my MSc thesis for the MSc by Research in Interactive Media degree.

Please read the following statements carefully and tick the appropriate box:

7.21 - Developer Interviews - In person interview Consent Form #

Department of Theatre, Film, Television and Interactive Media - Ethics Committee #

Participant Consent Form

Thank you for your interest in this project. This research activity will be used to understand how website developers try to develop accessible websites and their methods for doing so as part of my MSc thesis for the MSc by Research in Interactive Media degree.

Please read the following statements carefully and tick the appropriate box:

7.22 - Developer Interviews - Video call interviews Consent Form #

Department of Theatre, Film, Television and Interactive Media - Ethics Committee #

Participant Consent Form

Thank you for your interest in this project. This research activity will be used to understand how website developers try to develop accessible websites and their methods for doing so as part of my MSc thesis for the MSc by Research in Interactive Media degree.

Please read the following statements carefully and tick the appropriate box:

7.23 - Developer Interviews - Information sheet #

Investigating how personalisation affects perceived accessibility of interactive experiences #

Department of Theatre, Film, Television and Interactive Media - Ethics Committee

Participant Information Sheet - Anonymous Research

Project background

The University of York would like to invite you to take part in the following project: Investigating how personalisation affects the perceived accessibility of interactive experiences.

Before agreeing to take part, please read this information sheet carefully and let us know if anything is unclear or you would like further information.

What is the purpose of the project?

This project is being performed by Joe Lamyman (jl2160@york.ac.uk), a master’s student on the MSc by Research in Interactive Media degree at the University of York. This research is being undertaken as part of the MSc thesis, which is being supervised by Dr Anna Bramwell-Dicks (anna.bramwelldicks@york.ac.uk) and Dr Debbie Maxwell (debbie.maxwell@york.ac.uk).

The work that is being performed for the assessments within the module is being conducted according to restrictions that have been subject to approval by the TFTI Ethics committee. The Chair of the TFTI Ethics committee can be contacted on TFTI-ethics@york.ac.uk.

For this research project, we are interested in how website developers try to develop accessible websites and their methods for doing so. Your participation in this project will involve an interview lasting no longer than 30 mins. Interviews may be conducted in person, through video conferencing software or through an email exchange. If the interview is in person or through video conferencing software, I will be audio recording the interview and may take written notes on paper.

Please note that to comply with the approved Ethics requirements of this work, I do not intend to discuss sensitive topics with you that could be potentially upsetting or distressing. If you have any concerns about the topics that may be covered in the research study, please raise these concerns with the researcher.

Your participation in this project is voluntary. If you wish, I will provide you with access to the edited film and/or the report that we submit after our marks have been confirmed. If you would like to receive access to these, you can indicate as such on the consent form.

Why have I been invited to take part?

You have been invited to take part because I am aiming to recruit participants whose primary role is a website developer with a knowledge of accessible
web development, and I hope you might be interested in this work.

Do I have to take part?

No, participation is optional. If you do decide to take part, you will be given a copy of this information sheet for your records and will be asked to complete a participant consent form. If you change your mind at any point during the research activity, you will be able to withdraw your participation without having to provide a reason. To withdraw your participation you need to let the researcher know you wish to withdraw, and all your data will be deleted as soon as possible.

On what basis will you process my data?

Under the General Data Protection Regulation (GDPR), the University has to identify a legal basis for processing personal data and, where appropriate, an additional condition for processing special category data.

For further information and definitions of personal and special category data,
please go to:

• https://ico.org.uk/for-organisations/guide-to-the-general-dataprotection-regulation-gdpr/key-definitions/
• https://ico.org.uk/for-organisations/guide-to-the-general-dataprotection-regulation-gdpr/lawful-basis-for-processing/special-categorydata/

In line with our charter which states that we advance learning and knowledge by teaching and research, the University processes personal data for research purposes under Article 6 (1) (e) of the GDPR:

Processing is necessary for the performance of a task carried out in the
public interest

Special category data is personal data which the GDPR says is more sensitive, and so needs more protection. In this study, we will not be collecting any special category data.

Research activities will only be undertaken where ethical approval has been obtained, where there is a clear public interest and where appropriate safeguards have been put in place to protect data.

In line with ethical expectations and in order to comply with common law duty of confidentiality, we will seek your consent to participate where appropriate. This consent will not, however, be our legal basis for processing your data under the GDPR.

How will you use my data?

Data will be processed for the purposes outlined in this notice.

Will you share my data with 3rd parties?

No. Data will be accessible to the project team and personnel associated with the Department of Theatre, Film and Television at the University of York only.

Anonymised data may be reused by the research team or other third parties for secondary research purposes.

How will you keep my data secure?

The University will put in place appropriate technical and organisational measures to protect your personal data and/or special category data. For the purposes of this project we will be storing data using the secure University services provided by Google.

Information will be treated confidentiality and shared on a need-to-know basis only. The University is committed to the principle of data protection by design and default and will collect the minimum amount of data necessary for the Project.

Will you transfer my data internationally?

Possibly. The University’s cloud storage solution is provided by Google which means that data can be located at any of Google’s globally spread data centres. The University has data protection complaint arrangements in place with this provider. For further information see, https://www.york.ac.uk/itservices/google/policy/privacy/.

Will I be identified in any outputs?

No. Your participation in this research activity will be treated anonymously and you will not be identified in any outputs.

How long will you keep my data?

Data will be retained in line with legal requirements or where there is a business need. Retention timeframes will be determined in line with the University’s Records Retention Schedule.

What rights do I have in relation to my data?

Under the GDPR, you have a general right of access to your data, a right to rectification, erasure, restriction, objection or portability. You also have a right to withdrawal. Please note, not all rights apply where data is processed purely for research purposes. For further information see, https://www.york.ac.uk/records-management/generaldataprotectionregulation/individualsrights/.

Questions or concerns

If you have any questions about this participant information sheet or concerns about how your data is being processed, please contact the TFTI Ethics Chair (TFTI-ethics@york.ac.uk) in the first instance. If you are still dissatisfied, please contact the University’s Acting Data Protection Officer at dataprotection@york.ac.uk.

If you have any questions about the project itself, please contact the producer Joe Lamyman (jl2160@york.ac.uk) or project supervisors Dr Anna Bramwell-
Dicks (anna.bramwell-dicks@york.ac.uk) and Dr Debbie Maxwell (debbie.maxwell@york.ac.uk).

Right to complain

If you are unhappy with the way in which the University has handled your personal data, you have a right to complain to the Information Commissioner’s Office. For information on reporting a concern to the Information Commissioner’s Office, see www.ico.org.uk/concerns.

7.24 - Study 1 - Participant consent information displayed on the front page of the website #

Welcome!

What is this?

This is a game made by me, Joe Lamyman, Interactive Media student at the University of York, as part of my master’s thesis. This game allows you to answer questions and create your own e-commerce user interface based on your own needs.

Why does this exist?

This game is part of a student project for my thesis at University of York, UK. The purpose of this game is to understand user preferences and accessibility needs when using user interfaces.

The results from this game will help me to understand features of web user interfaces that can be personalised to enhance web accessibility.

After completing the game, you will be shown a personalised e-commerce website interface, and then asked to complete a short survey hosted by Google Forms to provide me with additional contextual data.

What will happen with the information I provide?

No personal information will be captured from this game. There are no cookies or analytical information being tracked either. After you have completed the game, you will complete an online survey hosted by Google Forms where we will collect some additional information to add context to your choices within the game, as well as demographic data about you. You will have the option to provide your email address to be entered into a prize draw for 1 of 10 £25 Amazon vouchers. If you wish to be entered into the prize draw you will need to complete the game and submit the Google Form by 12/09/2020.

The questionnaire will be asking about your accessibility requirements when using websites. As a result, we recognise that this has the potential to be a sensitive topic. The questions relating to this area will not be mandatory, so you do not have to provide an answer. In addition, you may withdraw your participation at any time. If you have not completed your questionnaire yet, this information will not be submitted. If you have already completed your website design, you can email us (details below) with your unique ID to remove your participation. You do not have to provide any reason for doing so, and may remove your participation at any time.

What should I do if I have any concerns?

If you have any questions please let me or my supervisors know by contacting us as follows:

• Joe Lamyman (jl2160@york.ac.uk) (student).
• Dr Anna Bramwell-Dicks (anna.bramwell-dicks@york.ac.uk) (supervisor).
• Dr Debbie Maxwell (debbie.maxwell@york.ac.uk) (supervisor).

Can I see more information?

You can view the full project information sheet here: Project information sheet which provides further information about the project and how we will use and store your data in line with the General Data Protection Regulation (GDPR).

To continue to the game, please consent to the following
[ ] I am over the age of 18.
[ ] I have read the information sheet.
[ ] I consent to my information being used anonymously in the project’s thesis and other research outputs (e.g. conference papers, journal articles)

7.25 - Study 1 - Participant information sheet #

Investigating how personalisation affects perceived accessibility of interactive experiences #

Department of Theatre, Film, Television and Interactive Media - Ethics Committee

Participant Information Sheet - Anonymous Research

Project background

The University of York would like to invite you to take part in the following project: Investigating how personalisation affects the perceived accessibility of interactive experiences. Before agreeing to take part, please read this information sheet carefully and let us know if anything is unclear or you would like further information.
What is the purpose of the project?

This project is being performed by Joe Lamyman (jl2160@york.ac.uk), a master’s student on the MSc by Research in Interactive Media degree at the University of York. This research is being undertaken as part of the MSc thesis, which is being supervised by Dr Anna Bramwell-Dicks (anna.bramwelldicks@ york.ac.uk) and Dr Debbie Maxwell (debbie.maxwell@york.ac.uk).
The work that is being performed is being conducted according to restrictions that have been subject to approval by the TFTI Ethics committee. The Chair of the TFTI Ethics committee can be contacted on TFTI-ethics@york.ac.uk.

For this research project, we are interested in features that a user would want to personalise to meet their own accessibility needs. In this context, the term accessibility would relate largely to the needs of disabled people, or more broadly, the needs of users when accessing a service. At this stage of the work, we are undertaking a pilot study of our test site to help us to identify any accessibility or usability issues with the main study materials and the process. If selected to take part in this pilot phase of this project, your involvement will require you to take part in the main study and also to provide us with feedback on accessibility and usability problems that you may encounter afterwards. Therefore, we would ask that while you undertake the main study, you keep note of any usability or accessibility issues that you encounter while working through the study. Participation in the pilot phase of this study will take no longer than 60 minutes using a website I have created. More details regarding participation in the main study itself will be provided in the information sheet that is embedded in the website for the main study.

Why have I been invited to take part?

You have been invited to take part after you indicated your interest in helping to test the website. We are accessibility testing the website, to ensure that the site is as accessible to as many people as possible, before releasing it to a wider audience. As we are currently in the testing stage, you may encounter some accessibility issues.

As a result, your participation at this stage will also involve providing detailed feedback on any accessibility issues encountered on the test site. This is to ensure that if there are any accessibility issues, these can be fixed before a wider release.

Do I have to take part?

After reading this information sheet, you will be asked to complete a participant consent form and answer some screening questions. If you wish to withdraw at this point, please contact Joe Lamyman (jl2160@york.ac.uk), and all your data will be deleted as soon as possible. If you are selected to take part in the pilot study conducting initial accessibility testing of the main study materials, Joe Lamyman will contact you and provide details on how to access the main study. To thank you for your participation in the pilot study, you will be provided with a £25 Amazon voucher. If you are not selected to take part in the pilot study, you will have the opportunity to take part in the general release of the study later where you would have the opportunity to win an Amazon voucher in a prize draw.

On what basis will you process my data?

Under the General Data Protection Regulation (GDPR), the University has to identify a legal basis for processing personal data and, where appropriate, an additional condition for processing special category data.

For further information and definitions of personal and special category data,
please go to:

• https://ico.org.uk/for-organisations/guide-to-the-general-dataprotection-regulation-gdpr/key-definitions/
• https://ico.org.uk/for-organisations/guide-to-the-general-dataprotection-regulation-gdpr/lawful-basis-for-processing/special-categorydata/

In line with our charter which states that we advance learning and knowledge by teaching and research, the University processes personal data for research purposes under Article 6 (1) (e) of the GDPR:

Processing is necessary for the performance of a task carried out in the
public interest

Special category data is personal data which the GDPR says is more sensitive, and so needs more protection. In this study, we will not be collecting any special category data.

Research activities will only be undertaken where ethical approval has been obtained, where there is a clear public interest and where appropriate safeguards have been put in place to protect data.

In line with ethical expectations and in order to comply with common law duty of confidentiality, we will seek your consent to participate where appropriate. This consent will not, however, be our legal basis for processing your data under the GDPR.

How will you use my data?

Data will be processed for the purposes outlined in this notice.

Will you share my data with 3rd parties?

No. Data will be accessible to the project team and personnel associated with the Department of Theatre, Film and Television at the University of York only.

Anonymised data may be reused by the research team or other third parties for secondary research purposes.

How will you keep my data secure?

The University will put in place appropriate technical and organisational measures to protect your personal data and/or special category data. For the purposes of this project we will be storing data using the secure University services provided by Google.

Information will be treated confidentiality and shared on a need-to-know basis only. The University is committed to the principle of data protection by design and default and will collect the minimum amount of data necessary for the Project.

Will you transfer my data internationally?

Possibly. The University’s cloud storage solution is provided by Google which means that data can be located at any of Google’s globally spread data centres. The University has data protection complaint arrangements in place with this provider. For further information see, https://www.york.ac.uk/itservices/google/policy/privacy/.

Will I be identified in any outputs?

No. Your participation in this research activity will be treated anonymously and you will not be identified in any outputs.

How long will you keep my data?

Data will be retained in line with legal requirements or where there is a business need. Retention timeframes will be determined in line with the University’s Records Retention Schedule.

What rights do I have in relation to my data?

Under the GDPR, you have a general right of access to your data, a right to rectification, erasure, restriction, objection or portability. You also have a right to withdrawal. Please note, not all rights apply where data is processed purely for research purposes. For further information see, https://www.york.ac.uk/records-management/generaldataprotectionregulation/individualsrights/.

Questions or concerns

If you have any questions about this participant information sheet or concerns about how your data is being processed, please contact the TFTI Ethics Chair (TFTI-ethics@york.ac.uk) in the first instance. If you are still dissatisfied, please contact the University’s Acting Data Protection Officer at dataprotection@york.ac.uk.

If you have any questions about the project itself, please contact the producer Joe Lamyman (jl2160@york.ac.uk) or project supervisors Dr Anna Bramwell-
Dicks (anna.bramwell-dicks@york.ac.uk) and Dr Debbie Maxwell (debbie.maxwell@york.ac.uk).

Right to complain

If you are unhappy with the way in which the University has handled your personal data, you have a right to complain to the Information Commissioner’s Office. For information on reporting a concern to the Information Commissioner’s Office, see www.ico.org.uk/concerns.

7.26 - Study 2 - Participant consent Google Form #

Department of Theatre, Film, Television and Interactive Media - Ethics Committee #

Participant Consent Form

Thank you for your interest in this project. This research activity will be used to understand how website developers try to develop accessible websites and their methods for doing so as part of my MSc thesis for the MSc by Research in Interactive Media degree.

Please read the following statements carefully and tick the appropriate box:

7.27 - Study 2 - Participant information sheet #

Investigating how personalisation affects perceived accessibility of interactive experiences #

Department of Theatre, Film, Television and Interactive Media - Ethics Committee

Participant Information Sheet - Anonymous Research

Project background

The University of York would like to invite you to take part in the following project: Investigating how personalisation affects the perceived accessibility of interactive experiences.
Before agreeing to take part, please read this information sheet carefully and let us know if anything is unclear or you would like further information.

What is the purpose of the project?

This project is being performed by Joe Lamyman (jl2160@york.ac.uk), a master’s student on the MSc by Research in Interactive Media degree at the University of York. This research is being undertaken as part of the MSc thesis, which is being supervised by Dr Anna Bramwell-Dicks (anna.bramwell-dicks@york.ac.uk) and Dr Debbie Maxwell (debbie.maxwell@york.ac.uk).
The work that is being performed for the assessments within the module is being conducted according to restrictions that have been subject to approval by the TFTI Ethics committee. The Chair of the TFTI Ethics committee can be contacted on TFTI-ethics@york.ac.uk.

For this research project, we are interested in features that a user would want to personalise to meet their own accessibility needs. In this context, the term accessibility would relate largely to the needs of disabled people, or more broadly, the needs of users when accessing a service. Your participation in this project will involve completing a series of tasks within an e-commerce website that I have created, and then answering a short survey and interview afterwards. The whole session will last no longer than 60 minutes. I plan on screen and audio recording the session and may take written notes on paper. As I will be screen recording, if you are using a webcam, video footage from the webcam will be visible on screen and recorded. Please note that to comply with the approved Ethics requirements of this work, we do not intend to discuss sensitive topics with you that could be potentially upsetting or distressing. If you have any concerns about the topics that may be covered in the research study, please raise these concerns with the researcher.

Your participation in this project is voluntary. If you wish, we will provide you with access to the report or any outcomes after submission and mark ratification. If you would like to receive access to these, you can indicate as such on the consent form.

Why have I been invited to take part?

You have been invited to take part after you indicated your interest in helping to test future parts of the project. We are usability testing an e-commerce website, to ensure that the site is as accessible to as many people as possible.

Do I have to take part?

No, participation is optional. If you do decide to take part, you will be given a copy of this information sheet for your records and will be asked to complete a participant consent form. If you change your mind at any point during the research activity, you will be able to withdraw your participation without having to provide a reason. To withdraw your participation you need to let Joe Lamyman (jl2160@york.ac.uk) know you wish to withdraw, and all your data will be deleted as soon as possible.

On what basis will you process my data?

Under the General Data Protection Regulation (GDPR), the University has to identify a legal basis for processing personal data and, where appropriate, an additional condition for processing special category data.

For further information and definitions of personal and special category data,
please go to:

• https://ico.org.uk/for-organisations/guide-to-the-general-dataprotection-regulation-gdpr/key-definitions/
• https://ico.org.uk/for-organisations/guide-to-the-general-dataprotection-regulation-gdpr/lawful-basis-for-processing/special-categorydata/

In line with our charter which states that we advance learning and knowledge by teaching and research, the University processes personal data for research purposes under Article 6 (1) (e) of the GDPR:

Processing is necessary for the performance of a task carried out in the
public interest

Special category data is personal data which the GDPR says is more sensitive, and so needs more protection. In this study, we will not be collecting any special category data.

Research activities will only be undertaken where ethical approval has been obtained, where there is a clear public interest and where appropriate safeguards have been put in place to protect data.

In line with ethical expectations and in order to comply with common law duty of confidentiality, we will seek your consent to participate where appropriate. This consent will not, however, be our legal basis for processing your data under the GDPR.

How will you use my data?

Data will be processed for the purposes outlined in this notice.

Will you share my data with 3rd parties?

No. Data will be accessible to the project team and personnel associated with the Department of Theatre, Film and Television at the University of York only.

Anonymised data may be reused by the research team or other third parties for secondary research purposes.

How will you keep my data secure?

The University will put in place appropriate technical and organisational measures to protect your personal data and/or special category data. For the purposes of this project we will be storing data using the secure University services provided by Google.

Information will be treated confidentiality and shared on a need-to-know basis only. The University is committed to the principle of data protection by design and default and will collect the minimum amount of data necessary for the Project.

Will you transfer my data internationally?

Possibly. The University’s cloud storage solution is provided by Google which means that data can be located at any of Google’s globally spread data centres. The University has data protection complaint arrangements in place with this provider. For further information see, https://www.york.ac.uk/itservices/google/policy/privacy/.

Will I be identified in any outputs?

No. Your participation in this research activity will be treated anonymously and you will not be identified in any outputs.

How long will you keep my data?

Data will be retained in line with legal requirements or where there is a business need. Retention timeframes will be determined in line with the University’s Records Retention Schedule.

What rights do I have in relation to my data?

Under the GDPR, you have a general right of access to your data, a right to rectification, erasure, restriction, objection or portability. You also have a right to withdrawal. Please note, not all rights apply where data is processed purely for research purposes. For further information see, https://www.york.ac.uk/records-management/generaldataprotectionregulation/individualsrights/.

Questions or concerns

If you have any questions about this participant information sheet or concerns about how your data is being processed, please contact the TFTI Ethics Chair (TFTI-ethics@york.ac.uk) in the first instance. If you are still dissatisfied, please contact the University’s Acting Data Protection Officer at dataprotection@york.ac.uk.

If you have any questions about the project itself, please contact the producer Joe Lamyman (jl2160@york.ac.uk) or project supervisors Dr Anna Bramwell-
Dicks (anna.bramwell-dicks@york.ac.uk) and Dr Debbie Maxwell (debbie.maxwell@york.ac.uk).

Right to complain

If you are unhappy with the way in which the University has handled your personal data, you have a right to complain to the Information Commissioner’s Office. For information on reporting a concern to the Information Commissioner’s Office, see www.ico.org.uk/concerns.

7.28 - The Bog Roll Business Builder Website #

The Bog Roll Business Builder website is still live and can be found via the following web address: https://bog-roll-business-builder.netlify.app/. Please note, the website is slightly altered as it is no longer capturing contextual information or displaying the Google Form to the user.

8 - References #

Apple (2020) Human Interface Guidelines. Available from https://developer.apple.com/design/human-interface-guidelines/ [accessed 9 April 2020].

American Bar Association (2019) How Courts Work. Available from https://www.americanbar.org/groups/public_education/resources/law_related_education_network/how_courts_work/discovery.html/ [accessed 29 August 2020].

Americans with Disabilities Act of 1990, Public Law 101-136. United States of America. Available at https://www.govinfo.gov/content/pkg/STATUTE-104/pdf/STATUTE-104-Pg327.pdf [accessed 1 September 2020].

Andrews, R. (2018). Using Media Queries For Responsive Design In 2018. [online] Smashing Magazine. Available at: https://www.smashingmagazine.com/2018/02/media-queries-responsive-design-2018/ [Accessed 12 Dec. 2019].

Aronowitz, A. A. (2009) Human Trafficking, Human Misery: The Global Trade in Human Beings. Greenwood Publishing Group.

Bagaar (2020) User Inyerface. Available from https://userinyerface.com/ [accessed 25th October 2020].

Bell, A. (2020) CUBE CSS. Available from https://piccalil.li/blog/cube-css/ [accessed 22 November 2020].

Bethesda Game Studios (2011-2018) The Elder Scrolls V: Skyrim. Bethesda Softworks.

Bolton, J. and Levine, J. (2016) Using Design Tokens with the Lightning Design System [video]. Available from https://www.youtube.com/watch?v=wDBEc3dJJV8 [accessed 8 April 2020].

Bootstrap (2020) Bootstrap v4.5 [software]. Available from https://getbootstrap.com/docs/4.5/getting-started/download/ [accessed 8 November 2020].

Brignull, H. and Darlo, A. (2019) Types of dark pattern. Dark Patterns. Available from https://www.darkpatterns.org/types-of-dark-pattern [accessed 6 April 2020].

Brooks, A. (2015) Clothing Poverty: The Hidden World of Fast Fashion and Second-Hand Clothes. Zed Books Ltd.

Brownlow, S. and Williams, R. (2020) The Click-Away Pound Report 2019. Freeney Williams Limited. Brighton. Available from http://www.clickawaypound.com/downloads/cap19final0502.pdf> [accessed 8 August 2020].

Butler, S. (2019) And they're off … £6.8bn Christmas ad spree gets under way. London: The Guardian. Available from: https://www.theguardian.com/business/2019/nov/02/and-theyre-off-68bn-christmas-ad-spree-gets-under-way [accessed 21st February 2020].

CD Projekt Red (2015-2019) The Witcher 3: Wild Hunt. CD Projekt.

Churchill, E. (2019). Scaling UX with design systems. Interactions, 26(5), 22–23. <https://doi.org/10.1145/3352681

Commission of the European Communities (2009) Internet of Things - An action plan for Europe. Available from https://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2009:0278:FIN:EN:PDF [accessed 9 April 2020].

CowKiller (2017) Better font and Bigger subtitles. Available from https://www.nexusmods.com/witcher3/mods/2759/?tab=posts [accessed 24 March 2020].

Davis, N. (2020) Fast fashion speeding toward environmental disaster, report warns. London: The Guardian. Available from https://www.theguardian.com/fashion/2020/apr/07/fast-fashion-speeding-toward-environmental-disaster-report-warns [accessed 21 November 2020].

Deque Systems (2020) ‌axe - Web Accessibility Testing. Available from https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd [accessed 30th October 2020].

Disability Rights Commission (2004) The Web: Access and Inclusion for Disabled People - A Forman Investigation conducted by the Disability Rights Commission. London. Available from https://www.city.ac.uk/__data/assets/pdf_file/0004/72670/DRC_Report.pdf [accessed 4 April 2020].

Drasner, S. (2020) ‌Is this a sandwich?. Available from https://isthisasandwich.netlify.app/ [accessed 25th October 2020].

Dodson, R. (2016) CSS Variables: Why Should You Care?. Available from https://developers.google.com/web/updates/2016/02/css-variables-why-should-you-care [accessed 26th October 2020].

Elan, P. (2019) Race shouldn’t be going in and out of fashion. We need a fully diverse industry. London: The Guardian. Available from https://www.theguardian.com/commentisfree/2019/nov/05/race-fashion-industry-diversity-insensitivity [accessed 21 November 2020].

European Union (2016) Directive (EU) 2016/2102 of the European Parliament and of the Council of 26 October 2016 on the accessibility of the websites and mobile applications of public sector bodies. Available from https://eur-lex.europa.eu/legal-content/en/TXT/?uri=CELEX%3A32016L2102 [accessed 16 November 2019].

Equality Act 2010 (c.2). London. Available from https://www.legislation.gov.uk/ukpga/2010/15/section/20 [accessed 29 July 2020].

Facebook Inc. (2020) React [JavaScript library]. California: Facebook. Available from https://reactjs.org/ [accessed 1 August 2020].

Frost, B. (2016). Atomic Design. Brad Frost.

Frost, B. (2016) Chapter 2 - Atomic Design Methodology - Atoms, molecules, organisms, templates and pages. Available from: https://atomicdesign.bradfrost.com/chapter-2/ [accessed 9 April 2020].

Gonçalves, R., Rocha, T., Martins, J., Branco, F., Au-Yong-Oliveira, M. (2017) Evaluation of e-commerce websites accessibility and usability:an e-commerce platform analysis with the inclusion of blind users. Springer.

Google Inc. (2018) Google’s Year In Search - Google Trends. Available from https://trends.google.com/trends/yis/2018/US/ [accessed 22 November 2020].

Google (2020) Lighthouse. Available from https://web.dev/measure/ [accessed 30th October 2020].

Government Digital Service (2018) Understanding accessibility requirements for public sector bodies. London: GOV.UK. Available from: https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps [accessed 18 January 2020].

Government Digital Service (2019) Making your service accessible: an introduction. London: GOV.UK. Available from: https://www.gov.uk/service-manual/helping-people-to-use-your-service/making-your-service-accessible-an-introduction [accessed 21 March 2020].

Gray, C., You, Y., Battles, B., Hoggatt, J., Toombs, A. (2018) The Dark (Patterns) Side of UX Design. In: CHI '18: Proceedings of the 2018 CHI Conference on Human Factors in Computing Systems. Pages 1-14.

Gregor, P., & Newell, A. F. (2001). Designing for dynamic diversity - Making accessible interfaces for older people. Proceedings of the 2001 EC/NSF Workshop on Universal Accessibility of Ubiquitous Computing: Providing for the Elderly, WUAUC 2001, 90–92.

Henry, S. (2018) W3C Web Content Accessibility Guidelines (WCAG) Overview. W3C. Available from: https://www.w3.org/WAI/standards-guidelines/wcag/ [accessed 19th December 2019].

Henry, S. (2019) Introduction to Web Accessibility. W3C. Available from https://www.w3.org/WAI/fundamentals/accessibility-intro/ [accessed 4 April 2020].

Hick, W.E. (1952) On the rate of gain of information. Quarterly Journal of Experimental Psychology, 4:1, 11-26.

Hyman, R. (1953) Stimulus information as a determinant of reaction time. Available from https://pdfs.semanticscholar.org/ [accessed 8 November 2020].

Ji, H., Yun, Y., Lee, S., Kim, K., & Lim, H. (2017). An adaptable UI/UX considering user’s cognitive and behavior information in distributed environment. Cluster Computing, 21(1), 1–14.

Kalbag, L. (2017) Accessibility for everyone. A Book Apart. Available from: https://abookapart.com/products/accessibility-for-everyone [accessed 8 August 2020].

Lazar, J., Dudley, A. and Greenidge, K-D. (2004) Improving web accessibility: a study of webmaster perceptions. Computers in Human Behaviour.

Level Access (2018) Ninth Circuit Reverses Robles v. Dominos Pizza LLC, Holds ADA Title III Suits Don’t Violate Due Process Rights. Available from https://www.levelaccess.com/ninth-circuit-reverses-robles-v-dominos-pizza-llc-holds-ada-title-iii-suits-dont-violate-due-process-rights/ [accessed 29 August 2020].

Lopes, R., Votis, K., Carriço, L., Tzovaras, D., & Spiridon, L. (2010). The semantics of personalised web accessibility assessment. Proceedings of the ACM Symposium on Applied Computing, 1440–1441.

Marcotte, E. (2010) Responsive Web Design. A List Apart. Available from https://alistapart.com/article/responsive-web-design/ [accessed 9 April 2020].

Mathur, A., Acar, G., Freidman, M., Lucherini, E., Mayer, J., Chetty, M., Narayanan, A. (2019) Dark Patterns at Scale: Findings from a Crawl 11K Shopping Websites. In: ‌Proceedings of the ACM on Human-Computer Interaction. Article 81.

MGE (2019) IMAGINATOR - Visual Control Device for Skyrim. Available from https://www.nexusmods.com/skyrimspecialedition/mods/4577 [accessed 24 March 2020].

Mozilla (2020) MDN Web Docs - ARIA live regions - Accessibility. Available from https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions [accessed 31st October 2020].

Mozilla (2020) MDN Web Docs - Custom properties (--): CSS variables. Available from https://developer.mozilla.org/en-US/docs/Web/CSS/--* [accessed 26th October 2020].

Mozilla (2020) MDN Web Docs Syntax - CSS. Available from https://developer.mozilla.org/en-US/docs/Web/CSS/Syntax#CSS_declaration_blocks [accessed 8 November 2020].

Nielsen, J. (1993) Usability Engineering. Elsevier Science & Technology.

Norman, D. (2013) The Design of Everyday Things, Revised and Expanded Edition. London, England: The MIT Press.

Norman, D. (2019) I wrote the book on user-friendly design. What I see today horrifies me. The Fast Company. Available from https://www.fastcompany.com/90338379/i-wrote-the-book-on-user-friendly-design-what-i-see-today-horrifies-me [accessed 9 December 2019].

Office for National Statistics. (2020) Retail sales, Great Britain: February 2020. Available from: https://www.ons.gov.uk/businessindustryandtrade/retailindustry/bulletins/retailsales/february2020 [accessed 6 April 2020].

Pickering, H. (2017) Inclusive Design Principles: Be Consistent. The Paciello Group. Available from https://developer.paciellogroup.com/blog/2017/08/inclusive-design-principle-be-consistent/ [accessed 25 March 2020].

Power, C., Freire, A. P., Petrie, H., & Swallow, D. (2012). Guidelines are only half of the story: Accessibility problems encountered by blind users on the Web. Conference on Human Factors in Computing Systems - Proceedings, 433–442.

Pun, K. (2016) Dos and don'ts on designing for accessibility. London. Available from https://accessibility.blog.gov.uk/2016/09/02/dos-and-donts-on-designing-for-accessibility/ [accessed 30th August 2020].

Reddy-Best, K. L., Kane, L., Harmon, J., Gagliardi, N. R. (2017) Critical perspectives on fashion textbooks: representations of race, gender, and body. International Journal of Fashion Design, Technology and Education, 11(1), 63-75.

Roberts, H. (2013) MindBEMding – getting your head ’round BEM syntax. Available from https://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/ [accessed 21 November 2020].

Robles v Domino’s Pizza, LLC [2019] United States Court of Appeals for the Ninth Circuit. Available from https://cases.justia.com/federal/appellate-courts/ca9/17-55504/17-55504-2019-01-15.pdf?ts=1547575304 [accessed 29 August 2020].

Roselli, A. (2020) #accessiBe Will Get You Sued. Available from https://adrianroselli.com/2020/06/accessibe-will-get-you-sued.html [accessed 22 August 2020].

Rubin, H.J, and Rubin, I.S (2005) Qualitative interviewing (2nd ed.): the art of hearing data, 2nd edn, SAGE Publications, Inc., Thousand Oaks, California,> [accessed 5 August 2020], doi: 10.4135/9781452226651.

Sass team (2020) Sass: Syntactically Awesome Style Sheets. Available from <https://sass-lang.com/[accessed 26th October 2020].

Silva, R. (2019) There’s a gap in the market — the value of disabled people. London: Evening Standard. Available from: https://www.standard.co.uk/comment/comment/there-s-a-gap-in-the-market-the-value-of-disabled-people-a4109456.html [accessed 22 January 2020].

Smashing Magazine. (2011). Responsive Web Design - What It Is And How To Use It. [online] Available at: https://www.smashingmagazine.com/2011/01/guidelines-for-responsive-web-design/ [accessed 12 Dec. 2019].

Sohaib, O. and Kang, K. (2016) Assessing Web Content Accessibility of E-Commerce Websites for People with Disabilities. In: 25th International Conference on Information Systems Development. Pages 466-475.

statcounter (2020) Desktop vs Mobile vs Tablet Market Share Worldwide Nov 2009 - Nov 2020. Available from https://gs.statcounter.com/platform-market-share/desktop-mobile-tablet/worldwide/#monthly-200911-202011 [accessed 13 Dec. 2020].

statcounter (2020) Screen Resolution Stats Worldwide Nov 2009 - Nov 2020. Available from https://gs.statcounter.com/screen-resolution-stats#monthly-200911-202011 [accessed 13 Dec. 2020].

State of CSS (2019) The State of CSS 2019: CSS Frameworks. Available from https://2019.stateofcss.com/technologies/css-frameworks/ [accessed 8 November 2020].

Stuerzlinger, W., Chapuis, O., Phillips, D., & Roussel, N. (2008). User interface façades: Towards fully adaptable user interfaces. UIST 2006: Proceedings of the 19th Annual ACM Symposium on User Interface Software and Technology, 309–318.

Tech Nation. (2018) Diversity and inclusion in UK tech companies. Available from https://technation.io/insights/diversity-and-inclusion-in-uk-tech-companies/ [accessed 10 December 2020].

Turner, G. and Barrick., K. (2019) Exclusive online retail experiences [Twitter] [Video]. 2 December. Available from https://twitter.com/5_News/status/1201579110142824448 [accessed 16 January 2020].

University of Washington (2019) How does accessible web design benefit all web users?. Washington. Available from https://www.washington.edu/doit/how-does-accessible-web-design-benefit-all-web-users [accessed 4 April 2020].

Utah State University (2019) WAVE Web Accessibility Evaluation Tool [software]. Logan, Utah: Utah State University. Available from: https://wave.webaim.org/extension/ [accessed 3 April 2020].

W3C (1999) Web Content Accessibility Guidelines 1.0. W3C. Available from https://www.w3.org/TR/WAI-WEBCONTENT/ [accessed 4 April 2020].

W3C (2012) The W3C Markup Validation Service. Available from https://validator.w3.org/ [accessed August 30th 2020].

W3C (2018) Web Content Accessibility Guidelines 2.1. W3C. Available from https://www.w3.org/TR/WCAG21/ [accessed 4 April 2020].

W3C (2019) Web Accessibility Tutorials: Grouping Controls. Available from https://www.w3.org/WAI/tutorials/forms/grouping/ [accessed September 3rd 2020].

W3C (2020) List of CSS properties, both proposed and standard. Available from https://www.w3.org/Style/CSS/all-properties.en.html [accessed 8 November 2020].

WebAIM (2017). Designing for Screen Reader Compatibility. Available from: https://webaim.org/techniques/screenreader/ [accessed 4 April 2020].

WebAIM. (2019). The WebAIM Million - An accessibility analysis of the top 1,000,000 home pages. [online] Available at: https://webaim.org/projects/million/ [accessed 12 Dec. 2019].

Weld, D. S., Anderson, C., Domingos, P., Etzioni, O., Gajos, K., Lau, T., & Wolfman, S. (2003). Automatically personalizing user interfaces. IJCAI International Joint Conference on Artificial Intelligence, 1613–1619.

Wilson, C. (2014) Interview techniques for UX practitioners: a user-centred design method. Waltham, MA: Morgan Kaufmann.

World Health Organization. (2020) Disabilities. World Health Organization. Available from http://origin.searo.who.int/topics/disabilities/en/> [accessed 25 November 2020].

World Wide Web Consortium (2018) CSS Flexible Box Layout Module Level 1. Available from https://www.w3.org/TR/css-flexbox-1/ [accessed 27 March 2020].

World Wide Web Consortium (2017) CSS Grid Layout Module Level 1. Available from https://www.w3.org/TR/css-grid-1/ [accessed 27 March 2020].

World Wide Web Foundation (2020) Contract for the Web. Available from https://contractfortheweb.org/ [accessed 9 April 2020].

Yigitbas, E., Sauer, S., & Engels, G. (2017). Adapt-UI: An IDE supporting model-driven development of self-adaptive UIs. Proceedings of the ACM SIGCHI Symposium on Engineering Interactive Computing Systems, EICS 2017, (October), 99–104. https://doi.org/10.1145/3102113.3102144