Inclusive Design

Every decision made when designing in any domain has the potential to include or exclude people. The inclusive design emphasizes the contribution that understanding user diversity makes to inform these decisions, and thus to include as many people as possible. The objective of Inclusive or Universal Design is to design products and environments that are usable by everyone, to the greatest extent possible, without the need for adaptation or specialised design (Clarkson, n.d.).

With that in mind, I set out to ensure that the redesigned Requirements Sign-off section of PPA would be built using an inclusiveness first approach, similar to mobile first (Quesenbery, 2010), so that there should be little to no need for my primary persona to require any form of adaptive technology such as screen readers or font enlargement.


For the colour palette, I decided to stick with Revenues primary colours combined with a section of the greys from the MS Fabric (fig 1)

Fig 1: Colour palette

As a colour palette on its own, there are no real issues with these colours, where issues can arise is when fonts are combined with it in various sizes and colourings. Poor contrast between foreground and background colours can lead to difficulties for users with various types of visual impairments such as colour blindness, or as in the case of the primary persona macular degeneration.

Font Legibility

To meet the level AA success criteria text smaller than 18 point (or 14 point if bold) must have a 4.5:1 contrast ratio. All larger text must have a contrast ratio of 3:1 or greater. The more stringent AAA criteria requires text under 18 point (or 14 point if bold) to exceed a contrast ratio of 7:1. All larger text must have a contrast ratio of at least 4.5:1. (, n.d.)

With the minimum font size for PPA being set to 16pt what remained was to ensure that contrast ratio met the W3 guidelines. below is the various combinations of background colour and font colour and their contrast ratio scores.

To demonstrate the colour contrast I have provided a screenshot below of each colour combination with the results from contrast checker.

Titles and headings

  • White (#FFFFFF) on Green (#025E63)
Fig 2: Main Headings
Fig 3: Main Headings W3 contrast test result

Main Menu

  • White (#FFFFFF) on Dark Grey(#333333)
  • Dark Grey (#333333) on Secondary Green(#00C6C6)
  • Black  (#000000) on Light Grey(#A6A6A6)
Fig 4 Main Menu
Fig 5: Main Menu W3 contrast test result – (#FFFFFF) on (#333333)
Fig 6: Main Menu W3 contrast test result –  (#333333) on (#00C6C6)
Fig 7: Main Menu W3 contrast test result – (#000000) on (#A6A6A6)

In the colour contrast results in Figure 7, the combination of colours fails the WCAG AAA test for normal text. This would not be an issue as the text in question is the active menu item which is 17pt and semibold putting it above the requirement of 14pt & bold

Content Areas

The majority of content sits either on a grey background (#f4f4f4) or white (#ffffff). To check the colour contrast across the PPA application I check will use the requirement and functional date input screens as most the screens use this colour combination for content (fig 8).

  • Dark Grey (#333333) on Light Yellow(#FBF6CF)
  • Grey (#626262) on Washed Grey(#F4F4F4)
  • Dark Grey (#333333)on Washed Grey(#F4F4F4)
Fig 8: Main Content colours
Fig 9: Main Content W3 contrast test result – (#000000) on (#FBF6CF)
Fig 11: Main Content W3 contrast test result – (#333333) on (#F4F4F4)
Fig 12: Main Content W3 contrast test result – (#626262) on (#F4F4F4)

Once again even though there is fail in figure 10, in this case, the non-active tab text, this would be negated by the size of the font being used


Besides the menu system itself, there are 3 buttons throughout the site. The link button, a back button ans the standard HTML form button.

Fig 13: Main inline buttons

  • Blue (#106EBE) on Washed Grey(#F4F4F4)
  • Blue (#106EBE) on White (#FFFFFF)
  • White (#FFFFFF) on Blue (#106EBE)
Fig 13: Buttons W3 contrast test result – (#106EBE) on (#F4F4F4)
Fig 14: Buttons W3 contrast test result – (#106EBE) on (#FFFFFF)
Fig 14: Buttons W3 contrast test result – (#FFFFF) on (#106EBE)

All the button links failed the WCAG AAA test for normal text. I don’t see this as a major issue due to the large font sizes but it is one worth taking a look at if a third iteration was to be carried out.


To aid first time users of the application both in-line and callout help was added. As users become more familiar with the application they can choose to disable the help function. If at a later date they require its assistance again they can re-enable it via the settings in the main menu. As discussed by Cooper Alan,‎ Reimann Robert,‎ Cronin David, (2014), this form of a guided tour has become quite common in mobile applications and is becoming more popular in web-based applications. They provide needed introduction to features through the use of screens or cards. The ability to disable it avoids the pitfall of it becoming an impolite technology constantly seeking attention such as Microsofts Office assistant Clippy, which was a huge failure (Shariat, 2016).


help001 help002

Fig 15: Help Screens

Requirements Sign off Process

The requirements process flow as previously discussed was broken out into separate stages, so as to make the process as simple as possible and reduce the amount of information on the screen. Also, the controls have been grouped together where possible. Grouping related controls can make the form more understandable for all users, as related controls are easier to identify (, n.d.). The dropdowns on PPA populate with content based on the previous drop-down selection, reducing the number of possible choices and in turn the cognitive load on the user.

The spacing between labels, inputs and text blocks were kept consistent with 8 and 16 pixels for padding so as to make legibility easy. For the labelling of inputs, I opted for the traditional label rather than placeholder text which has become quite popular, the reason being assistive technologies, such as screen readers, do not treat placeholder text as labels which can cause confusion for users (, n.d.)

Error messages appear beneath the inputs informing users of any issues. Spacing was checked for these to ensure they were clear and visible to the user and do not encroach on inputs or input labels causing confusion re mapping(fig 16, Screen 8).

Fig 16: Process Flow

Screen 4 is the main landing screen for the updating and viewing of requirements. The user can navigate directly to requirements selection screen at screen 6 or choose to view the delayed or missing dates requirements via screen 5 . Screen 4 was quite important to both personas as it allowed for an overview of requirements needing immediate attention. Fonts where kept especially large here allowing all types of users obtain an update at a glance.
From screen 4 the user can navigate to screen 5 which again uses large fonts and individual buttons with clear spacing as per the 8 base system. From here the user can navigate to the final screen Screen 8.

Final Requirements Screen

Most if not all of the inclusive design issues have already been covered in the above. There are one or two things which are particular to this section of the application which I will cover here.

The first of these are the tabs (fig 17), used to navigate between the requirement dates and the functional dates. These were kept quite large so as to make them easy to access not only for accessibility but also so that when holding the phone with one hand they are easily reachable with the thumb. The fonts have been kept quite large as they are primary action on the screen next to entering the dates.

Fig 17: Requirement & Functional screen

Although users hold phones in a variety of manners it would appear that predominant method for holding a phone is in the right hand and using the thumb to access controls. Over 40% of observations by Steven Hoober during his research into this topic, show users interacting with a mobile phone without inputting any data via key or screen (Hoober, 2013).

Fig 18: How Do Users Really Hold Mobile Devices (Hoober, 2013)

The final area for discussion is the calendar functionality, as previously discussed this had to be created from scratch and is informed by a mixture of Google Material, MS Fabric and the personas requirements. It functions by tapping the arrows moving the date item up or down to the desired input. Fonts have been kept especially large so as to make using it as easy as possible. The title of the input that is being populated has been set at the top of the window so that user does not need to switch back to check what they updated, and the selected date also appears here. I have chosen to display the day of the week as this can be an important consideration when setting sign off dates as releases are usually scheduled for mid-week. The background has been blurred so as to remove any distractions from the user

Fig 20: Calendar


It’s difficult to say how successful the inclusive design has been without user testing to check its usability. That aside a great amount of attention was paid to this section of the brief and I think adopting an inclusive first approach greatly helped. It will definitely be an approach I will consider for further work.

Although probably outside the scope of an interactive prototype the tabbing order is something that should be considered as well how HTML markup is managed. Both of these can have a huge effect on usability for user with screen readers (, (

The next and final post is a reflection and analysis of the work undertaken and will demonstrate the final high fidelity prototype.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at

Up ↑

%d bloggers like this: