Blogs Accessibility communications consulting

Documents: An accessibility conundrum


It’s been over three years since the accessibility legislation came into effect, and for many of us, despite the steep learning curve, heading structures, meaningful alt text and contextual link text are now part of our everyday life. 

What’s interesting is that more and more, we’re seeing the accessibility of digital platforms move out of the realms of being the responsibility of the digital or web team. Instead, we’re starting to see the transition to accessibility becoming embedded within organisations, which, if you ask me, is how it should be. Accessibility is everyone’s responsibility, it makes lives better.

The great conundrum

However, the conundrum I see time and again is around documents. When I run accessible content training workshops, this is when attendees realise that they’ve got a lot of work to do – this doesn’t make me very popular!

The main issue is typically centred upon the huge quantity of documents (Word docs, PDFs etc.) which are essentially “hanging around” on public sector websites – this is especially prevalent to local councils.

My three-tier approach to documents

With documents I have a three-tier approach:

  1. Remove them being sure to archive the content elsewhere
  2. Turn them in to HTML content
  3. Make the document accessible

One thing I will say is that it is rare that you can go with just one of the above, and in reality you’ll end up having to choose a combination approach when tackling your documents.

The plot thickens

However, once you start digging into the issues with your documents, it is not always as easy to fix as you might at first hope, for example:

  • What do you do about third party documents?
  • What about documents that are automatically produced by a supporting system?
  • Don’t forget forms!

I should add that the below isn’t official or legal advice, but instead how I would personally approach each scenario. 

I am very interested in hearing more from people who have tackled any of these issues, and what outcome you achieved, so if you want to chat please get in touch.

So what are the solutions? Let’s take them one by one.

accessibility and third-part documents

Accessibility and third-party documents

This is a tricky one. The phrase I have seen most frequently is that the document is exempt because it has been produced by a third party and the public body didn’t pay for it. However, the thing that niggles me is you have control of your website, so you can choose whether to publish this document or not. In some cases, it’s a small change that transforms a document into being accessible.

My preferred approach? I really like Worcestershire County Council’s Digital Accessibility Requirements, as an example of best practice. Its no nonsense, no exceptions approach should ensure that all documents produced by a third party are accessible or they’re not going on the website. I have seen this approach adopted by other councils too, and it is definitely effective.

documents produced by a supporting system

Documents produced by a supporting system

First things first, establish if this is a bespoke in-house system or one that is widely and/or commercially available.

For the former, have a talk with your in-house team and explain what needs to be done to make the output (in this case a document) accessible. It might be easier to fix than you think.

For the latter, I would start by going direct and asking the supplier. If they support similar public sector organisations, then there is a chance they’ve been asked this before and will have a plan to fix the issues, or already have and you will need to be upgraded. If you’re met with reluctance, questioning or having to explain your organisation’s position, then it might be time to check when the contract is up for renewal. Write your requirements into your spec and re tender when you can.

documents produced by a supporting system

Creating Accessible Forms

PDF or Word document forms are a pain. Ideally of course you invest in a forms package or a Customer Relationship Management (CRM) platform which blends seamlessly with your website. This h can provide not only an accessible option but also a better user experience for all – ever tried completing a PDF form on your phone?!

If this isn’t an option, has your Content Management System (CMS)  got a built in forms package? If so, this may offer an accessible user experience, but also act as a step change for your customer contact.

Failing that, you can try to make your PDF or Word forms accessible, it’s not always the prettiest and there are challenges. This should, in my opinion, be your worst case scenario as the  other two options are infinitely preferable. 

Thinking wider

In this meander, or blog if you prefer, we have really been talking about documents you want to add to your website, which date after September 2018. Documents created before then, unless deemed essential to accessing a service (such as application forms or how to guides) are exempt.

However, for me the move towards accessible documents should extend beyond just what you publish on your website or digital platform. For example, if you send a letter in the post and the customer prefers font size 18 are you providing that? What about the guidance you email out when a customer calls, is that formatted in an accessible way?

If you can move document accessibility out of the digital realm and into the wider world of businesses and good customer service, by taking the time to train your staff on how to create an accessible Word document as part of their induction for example.  Taking this approach moves accessibility from something you do if you need a document published online, to how your organisation works and interacts with people – for me I see no downsides.

Accessible documents are not just for websites.

Blogs business analysis communications consulting Solutions ux

Dyslexia Week 2021 – Keri Harrowven shares her story

As part of National Dyslexia Week the British Dyslexia Association has asked the dyslexic community to share their stories, to raise awareness and to help others with dyslexia feel understood.

Keri Harrowven, Digital Workplace Consultant at Invuse, – the new name for Invotra Consulting – shared her experience of dyslexia with us. Keri is keen to support the British Dyslexia Association’s belief that everyone with dyslexia has the power to create positive change, and she champions the work of Made By Dyslexia, that dyslexia is a superpower, with game changing strengths in creative, problem-solving and communication skills.

When did you realise that you were having challenges and that you were dyslexic?

At school I struggled with English, with reading, writing etc. When this was recognised by my teachers I was put in a ”special” class (an extra class on top of usual lessons) where they drummed into us the rules of grammar!

At no point did anyone use the word dyslexia. At parents evenings teachers would give my parents the feedback that I just couldn’t be bothered, and wasn’t trying or that I was clever, but lazy.

Thankfully I had parents who believed in me, knew I wasn’t lazy and didn’t let the comments from teachers dictate my confidence or my future opportunities.

It still breaks my heart that dyslexia isn’t picked up earlier in lots of cases.

How has dyslexia impacted you?

Dyslexia has given me the magical combination of being creative, detail focused and analytical. I feel confident this has been of great benefit throughout my career.

Now, working as a Digital Workplace Consultant at Invuse, I believe my dyslexic thinking skills enable me to uncover and analyse the detail of customers needs. Working with clients like Houses of Parliament, NHS Trusts and when onboarding all of our new clients, I feel dyslexia allows me to creatively deliver a great digital user experience.

What support or help have you received for your dyslexia?

I have had no support for my dyslexia! I had to teach myself to recognise the shape of words. I have to see a word written down, before I can begin to know how to spell it and write it myself.

Do you have an achievement or story, linked to your dyslexia, you would like to share?

I left school with only CSEs and did a year at sixth form to get my one O-level in Maths.

However, when I started work, I immediately could see that I was not actually ‘stupid’, as my teachers had so often made me feel. I was, infact really quite clever when it came to doing the things you need to succeed in the real world of work.
It was when I started working with computers, with a spell check that I really came into my own.

While working for the National Trust I created spreadsheets for the properties to record their daily income. This was previously done manually, on big sheets of paper. I then worked with a developer to build their first database system, to record the income, and this began my passion for delivering a great user experience. I’ve been working in digital development ever since.

I went on to build the first 3 intranets for the National Trust, moving into internal communications and I am now a Digital Workplace Consultant. My passion and knowledge of all things usability and accessibility continually grows. My work at Invuse ensures usability and accessibility are integral to all platforms, to deliver a great experience to all users.

Do you have any advice for someone who has recently been diagnosed with dyslexia, or who, like you, recognises they are dyslexic?

This is your superpower, and you can do anything you want with it. Check out Made By Dyslexia for inspiration for everything you can achieve.

Blogs business analysis communications consulting Solutions ux

How to prepare, and launch, your new website – The ultimate guide for website managers and content owners


We’ve all been there. At first, things were great, better than great even. Together you were a dynamic duo that others envied. But, now things have changed. While you want to evolve and progress, the other has stymied and stubbornly stays the same. Sure, they make a bit of effort but really you know things have come to an end, and you’re just delaying the inevitable. The longer you leave it the worse it gets, and the more complicated it will be to start afresh.

Websites. Anyone who has managed a website will most likely have been in this situation at one point or another. Your current website has run its course and whether it’s because you simply can’t build or adapt your existing site anymore, the code is no longer supported or the costs for updating and maintenance have spiralled – or a combination of all – we all know when it is time to start preparing for change.

Just knowing it is time to change doesn’t make it any easier to start though. If you’ve already got the proverbial t-shirt, you probably also have the scars to match. If this is your first time the prospect might be completely overwhelming.

For the purpose of this article, we’re assuming you already have buy-in from your leadership team/stakeholders to start looking around. So, ignoring the various hoops of procurement for now, let’s break this down into the steps you need to take to prepare.

Step 1: Discover what works, and what doesn't work, on your website now

Before deciding what changes should be made, you need to work out what’s working and not working for you now. Take a look at your existing site. What’s good, what’s bad and, most importantly, where are the gaps that you will need to review to meet the needs of your end users? For this step, you should cast the net wide.

Engage stakeholders

Start by speaking to your stakeholders to understand their vision and requirements for your new website. What problems could it solve for their team? How could it make their service more efficient?

Interview end users

Next come your end users. What do they think of your current site? Why are they visiting? Did they manage to complete their task/find out what they need? If you can form a focus group to explore some of the common themes in more detail.

Review your analytics

Take a deep dive into your stats and analytics – common search terms, length of time on the website, bounce rate – really take a close look so you understand how your site is performing.

Identify the ROT

Carry out a Redundant, Obsolete, and Trivial (ROT) analysis on your content, so you know what you’re dealing with. What you find here will help inform your project delivery timeline.

Learn from the successes and failures of your peers

Speak to people outside of your organisation. Depending on your industry sector people may be really happy to share their experiences with you. I’ve worked across the charity and public sector and normally a call or an email to another organisation will prove really useful, and other teams are more than happy to share.

Of course some desktop research doesn’t go amiss and if you can organise some soft market testing or demos with suppliers even better.

Step 2: Analyse the priorities for your new website

Analyse the priorities for your new website 1. Work out your requirements - remember to look at technical, legal and service 2. Decide on your priorities 3. Plan a roadmap to continuously evolve 4. Find out if any requirements would be better delivered by a different application 5. Include development and ongoing support in your requirements 6. Benchmark and set some KPIs for your new site. 7. Create user personas to guide the design of your new site and content

So you’ve researched your socks off and spoken to everyone? It’s time to analyse.

Tease out the requirements for your new website from your research, don’t forget to look at technical, legal and service requirements you need to comply with, such as WCAG 2.1 Accessibility Guidelines.

You will also need to prioritise these requirements, what must your website have vs what would it be great if it could have? An approach I would always recommend using here is to create a 3, 6 and 12 month roadmap that allows you to continuously enhance your website. Use the MoSCoW (Must, Should, Could, Would) methodology to deliver the “Must haves” and “Should haves” for launch.

A word of warning here – when putting together the requirements for your website make sure you’re doing exactly that. It is easy to get carried away and add requirements for a whole host of additional functionality which support your digital roadmap, when actually that requirement is better served by a different application. The requirement here would be something along the lines of “ability to connect/integrate to a third party site, probably through the use of an API”.

Also make sure you think about what type of service model you will need to meet your ongoing needs, and put these into your requirements. If you don’t have an inhouse developer, make sure you include development and ongoing support in your requirements – you want to make sure you have a website that moves with you rather than finding that you’re stuck with an ailing website 18 months after launch.**

Now is also a good time to benchmark and set some KPIs for your new site. Of course your analytics are a great source for some of this information, but don’t forget to include some stats from your user surveys. If you work in an industry that is open to sharing information you may also have access to how other comparable organisation’s sites perform and want to include some of this information.

Spend time going through your user research and creating user personas. These will prove invaluable when you’re designing your new site and writing content. By really understanding your target audience, and their key user journey you can create a site and content which reflects and meets their needs.

*For those that know me well, you will know that right now I’m whispering (in my outdoor voice) – “Open Source”, “Drupal”, “Collaboration”.
**If you work in local government, the Local GovDrupal project is really worth taking a look at, for a true collaborative service and development model.

Step 3: Design your new website and implement your changes

Tender and procurement

Of course the first part of this is most likely the tender and procurement process – if you have a particular deadline you have to meet for the delivery of your new site, make sure you include this in the procurement process so that everyone is aware of your timescales.

Once you have your selected supplier, there will no doubt be a kick off meeting for the project and various steps they will need to take in order to deliver your new site.

Content and IA

My advice here, if you haven’t already, is to start thinking about your content and information architecture now. Use your user personas and ROT analysis to ensure your IA and content are clear and user friendly.

As part of your analysis you will have most likely looked at content and identified areas of improvement. If you move to your new site without addressing these issues the chances are your new site won’t be as successful as you’d like. It’s time to edit, rewrite and delete so that your new content truly meets the needs of your end users.

If your content is already in pretty good shape this can be straightforward, and you may even consider content migration and then editing on your new site instead. However, most of the projects I’ve been involved in have had a substantial amount of content work and I have opted to eschew content migration to ensure that everything has been looked at.

You don’t have to do this alone – speak to the subject matter experts in your organisation, utilise your existing team or bring in a content specialist. I’d also suggest plenty of tea and an afternoon Hobnob to get you through.

New functionality

You also need to consider any new functionality you’re bringing in as part of your new site or that you need to connect with. Online forms, maps, payment portals, SSO, CRM, databases… make a list, get it on the project plan and start speaking to people now.

Design your new website and implement your changes 1. Agree deadline 2. Hold a kick off meeting 3. Use your user personas and ROT analysis to plan IA and update content 4. Complete any content migration 5. Consider any new functionality needed

Step 4: Maintain and evolve the amazing website you've created

Woohoo! It’s launch day. Due to your thorough preparation you are launching on schedule, you madly hit refresh while you wait for the new site to go live and once it does the sense of relief and accomplishment is fantastic. Perhaps you celebrate with a fancy coffee, or by booking that holiday you have been dreaming of since the start of this project.

But what else? Maintain and evolve. At the beginning you will most likely be focussed on ensuring that the site is performing as expected and making minor changes to content, but after that has worn off it’s time to think about what next. It might be that you have already identified what’s in scope for phase 2 of your project, in which case you can start to map this out and plan. If not it’s time to revisit your original discovery and map out what’s coming next for your website.

I’d also be tempted to rerun your user survey now, if you need to secure funding for the next step of your project these can be quite handy in building your business case and also provide an early indication on the success of your launch.

Once you’ve done this? See Step 1…

Maintain and evolve website 1. Ensure that your site runs as expected 2. Make your content changes 3. Map out what’s coming next for your website 4. Re-perform your user experience survey
Blogs business analysis communications consulting Solutions ux

Evolve your intranet with an agile approach

I’ve launched a few intranets over the last 20 years, however I found moving to an Agile framework truly set the intranet free!

To be perfectly honest I was probably a little sceptical the first time a development team said they wanted to use ‘Agile’. I had developed a good number of intranets over the years and ‘normal’ development approaches seemed to have worked fine in the past.

However I am always open to new challenges and happily signed up for ‘Certified Scrum Product Owner’ training and I really hit the jackpot. The trainer, Gabrielle Benefield (Evolve Beyond), was very experienced and extremely engaging. It was two days training but well worth making the time for, and by the end of the course I was hooked.

The basic steps of the Agile development framework are:

  • Gather the business requirements

    • Stakeholder interviews

    • User research

    • Business objectives

  • Analyse and break these requirements into the individual features and functionality to create a Product Backlog. Dan Radigan explains more in his article: The product backlog: your ultimate to-do list

  • Write ‘user stories’ for each item – “As an X, I want to Y, so I can Z”. This enables the developers and testers to understand who requires what, and why. One way of approaching this is a cognitive walkthrough, detailed in this blog by Brendan Carikas.

  • Work with the development team to estimate the time required to develop each item, then prioritise the items to deliver the Minimum Viable Products (MVP), to be ready to launch to the users

I was then ready to start the first ‘Sprint’, which in our case was two weeks long.

  1. On the first day of each ‘Sprint’ I met with the development team to go through the items I wanted them to work on

  2. Each morning I joined the ‘Stand up’ meeting with the development team to review the progress they had made the day before and hear what they would be doing that day. It also gave everyone a chance to ask any question that had arisen

  3. During the ‘Sprint’ we would meet to ‘Refine the Backlog’ to adjust and agree what were the priorities for the next ‘Sprint’

  4. As the developers finished each item in the ‘Sprint’ it was tested

  5. Then at the end of the ‘Sprint’ the developers demo each completed item

  6. And then it’s back to Step 1 to start the next ‘Sprint’

With Agile development, every bit of functionality becomes a moveable feast and can be refined and developed to hone the user experience.

It’s great because new requirements always come from left field and it allows you to re-prioritise features and functionality throughout the development process.

And after the go-live… Agile allows you to continue the development, to add new functionality and refine the intranet on an on-going basis. This ensures the intranet does not stand still and keeps the users engaged as new features are made available.

The Product Owner role proved to be time consuming but very satisfying! The quality of the end product is great if you put that time in, but it is well worth the effort.

My usability Golden Rules

I was very lucky to work with a great team of developers who with a little guidance from me soon came to share my own Golden Rules:

  • Technology should be invisible – no one cares what it’s built on

  • Never compromise on the quality of the user experience

  • And remember the user plea, ‘Don’t make me think!’

Blogs communications consulting Invotra Solutions

Keri Harrowven joins Invuse as Communications Implementation Consultant

Invuse – the new name for Invotra Consulting – has added to its team of consultants with Keri Harrowven, a Communications Implementation Consultant. Keri will work with new and existing customers to transform and deliver internal communications platforms that focus on business and user needs in a time where remote working is the new norm.

Keri Harrowven, Commuications Implementations Consultant

Keri brings 20 years of intranet, communications and knowledge management, with a strong background in agile development, delivering creative communications solutions and creating outstanding digital user experiences.

"We are delighted to welcome Keri into our team. We've known Keri for many years now and feel that her knowledge and experience in helping customers identify and overcome their communications challenges, will really strengthen the team and what we can offer new and existing customers."

Jamie Garrett, Invuse Managing Director

Invuse – the new name for Invotra Consulting – focuses on helping organisations with their internal communications strategies to enhance and deliver digital platforms that are designed with end users and data analytics at the core.

Invotra Group has spent over 5 years working with enterprise organisations ranging from 35 – 90,000+ employees, each having complex requirements and the need to constantly adapt and change. The structure of our services means organisations can look to Invuse for support at any stage of their project(s) for assistance, from discovery and research to support and maintenance.

Blogs Accessibility Apps consulting

Accessibility Guidelines: What’s new in WCAG 2.2?

What’s new in WCAG 2.2

The W3C is working on the next, and possibly last, 2.x version of the Web Content Accessibility Guidelines (WCAG). On 11 August 2020 a Working Draft of WCAG 2.2 was released for public comment.

As a W3C Working Draft, WCAG 2.2 is still a work in progress. It will almost certainly change before it becomes an official W3C Recommendation, but publishing periodic Working Drafts for public comment and review is part of W3C’s Process.

What do we know so far?

Based on the 11 August Working Draft, WCAG 2.2 introduces 9 new Success Criteria (SC), and upgrades 1 SC.

New Level A SC

There are 4 new Level A SC in WCAG 2.2:

2.4.1 Fixed Reference Points

When a web page or set of web pages is an electronic publication with pagebreak locators, a mechanism is available to navigate to each locator and each locator maintains its place in the flow of content, even when the formatting or platform change.

3.2.6 Findable Help

For single page Web applications or any set of Web pages, if one of the following is available, then access to at least one option is included in the same relative order on each page:

  • Human contact details;

  • Human contact mechanism;

  • Self-help option;

  • A fully automated contact mechanism.

3.3.7 Accessible Authentication

If an authentication process relies on a cognitive function test, at least one other method must also be available that does not rely on a cognitive function test.

3.3.8 Redundant Entry

For steps in a process, information previously entered by or provided to the user that is required on subsequent steps is either:

  • auto-populated, or

  • available for the user to select.

New Level AA SC

There are 4 new SC at Level AA in WCAG 2.2:

2.4.11 Focus Appearance (Minimum)

For the keyboard focus indicator of each User Interface Component, all of the following are true:

  • Minimum area: The focus indication area is greater than or equal to a 1 CSS pixel border of the focused control, or has a thickness of at least 8 CSS pixels along the shortest side of the element.

  • Change of contrast: The color change for the focus indication area has a contrast ratio of at least 3:1 with the colors of the unfocused state.

  • Adjacent contrast: The focus indication area has a contrast ratio of at least 3:1 against all adjacent colors for the minimum area or greater, or has a thickness of at least 2 CSS pixels.

  • Unobscured: The item with focus is not entirely hidden by author-created content.

2.5.7 Dragging

All functionality that uses a dragging movement for operation can be operated by a single pointer without dragging, unless dragging is essential.

2.5.8 Pointer Target Spacing

For each target, there is an area with a width and height of at least 44 CSS pixels that includes it, and no other targets, except when:

  • Enlarge: A mechanism is available to change the CSS pixel size of each target, or its spacing, so there is an area with a width and height of at least 44 CSS pixels that includes it, and no other targets;

  • Inline: The target is in a sentence or block of text;

  • User agent: The size of the target is controlled by the user agent and is not modified by the author;

  • Essential: A particular presentation of the target is essential to the information being conveyed.

3.2.7 Hidden Controls

Controls needed to progress or complete a process are visible at the time they are needed without requiring pointer hover or keyboard focus, or a mechanism is available to make them persistently visible.

New Level AAA SC

There is 1 new SC at Level AAA in WCAG 2.2:

2.4.12 Focus Appearance (Enhanced)

For the keyboard focus indicator of each User Interface Component, all of the following are true:

  • Minimum area: The focus indication area is greater than or equal to a 2 CSS pixel solid border around the control.

  • Change of contrast: Color changes used to indicate focus have a contrast ratio of at least 4.5:1 with the colors changed from the unfocused control.

  • Unobscured: No part of the focus indicator is hidden by author-created content.

Upgraded SC

SC 2.4.7 Is a Level AA SC under WCAG 2.1 but has been upgraded to Level A in WCAG 2.2.

Success Criterion 2.4.7 Focus Visible

Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.

What’s coming next?

The WCAG 2.2 Editors Draft is where changes are made before being approved by the Accessibility Guidelines Working Group. Editors Drafts are not stable but they do offer a glimpse of what may be coming in WCAG 2.2.

The WCAG 2.2 Working Draft is updated whenever the Accessibility Guidelines Working Group approves a set of changes. Although not completely stable, a Working Draft contains changes that have undergone peer review by the Working Group, so they are more settled than those in the Editors Draft.

Ultimately, WCAG 2.2 will become a Candidate Recommendation and then a Recommendation, and this is the point at which WCAG 2.2 becomes an official W3C standard and can no longer be changed.

In the meantime you can file issues and comment on discussions in the WCAG 2.2 Github repository, or send your comments to the Accessibility Guidelines Working Group by email.

Accessibility Guidelines: What’s new in WCAG 2.2?

Blogs communications consulting design Solutions

5 technical considerations when designing or procuring a new platform

Driving digital transformation can prove to be a challenging exercise with the vast number of options available. How do you choose a platform which aligns with your digital strategy and ecosystem?

The short answer is it completely depends on your strategy. Nonetheless, there are 5 considerations that should be reviewed whenever you design or procure a new platform.

Buy vs build

One of the first considerations for procuring a new platform is whether to build a bespoke solution in-house, buy one off the shelf, or go down the SaaS route.

There are advantages to each approach, but the main questions to answer are:

  • What problem are you trying to solve, and is there an out of the box solution/service which already solves it?
  • What are the associated costs?
  • When does the solution need to be delivered?

The last two points are notoriously difficult to get right if you plan on building a solution. Off-the-shelf and SaaS solutions commonly offer a transparent and fixed cost, or at least a predictable cost in terms of the latter, and are much faster to deploy and roll out to the wider business. The main trade-off here is less control over the application.

Data management & Integration

There’s nothing worse than having to manage the same data across multiple applications. In an ideal scenario, applications should only be concerned with the data they need to function, and any data that needs to be shared across applications should be managed between those applications to avoid duplication and a management overhead nightmare.

APIs can help alleviate this problem and help avoid reinventing the wheel by encouraging integration between applications in favour of rebuilding.

When deciding on a platform, consider:

  • What data needs to be shared between this application and existing applications?
  • What are the available options for managing data externally?
  • What APIs are available?
  • Would it be easier to integrate with certain parts of the application rather than replacing everything?

For example, if you need users to be able to authenticate against the application, you can automate the provisioning and de-provisioning process. This may come with an initial setup cost but will save a lot of manual intervention in the future.


This is somewhat related to the previous point. Generally speaking, the more data that is available over APIs, the more analytics can be gathered to help drive insights. This isn’t just related to APIs, there are plenty of other tools such as Google Analytics and Matomo which provide a different set of analytical tools, driven by the web traffic to the platform.

To be clear on the definitions:

Data: Information within the platform
Analytics: Discovering patterns and trends from that data
Insights: Obtaining value from those analytics to drive improvements throughout the organisation

The main considerations here are:

  • What analytics tools are available? (e.g. Google Analytics)
  • Outside of analytics tools, what is the availability of data which could be extracted by other means? (e.g. APIs, CSV extracts)

Analytics tools can help you answer many of the questions you face, to name a few:

  • Which areas of the platform are most popular?
  • How many users are using the platform on a regular basis?
  • Are there any parts of the platform which are redundant, and need a rethink/remove?
  • Where should we be focussing our energy with the platform in question?
  • What devices are users using to access the platform?
  • What time are users accessing different types of data?

Cross-platform support

Cross-platform support is basically a guarantee nowadays, especially with web applications. It’s easier than ever before to support working from mobile and tablet devices as well as a desktop.

More and more users expect this level of support from applications, whether that be to just check their calendar on their daily commute or to completely switch to a smaller device for certain types of work just based on preference.

Choosing a platform that enables this flexible approach to work will provide a better experience for end-users. Pair this with analytics and it will be easy to see which types of work are most popular with different platforms, and where to optimise certain areas of the platform.

Security & updates

Last but definitely not least, security. With cyber-attacks constantly on the rise, it’s crucial to make sure that your users and information are safe. As attacks evolve and become more advanced, so do the methods used to prevent them. Information security is something that needs to be constantly monitored and prevented, which in itself is a story for a separate blog. When specifically talking about securing a platform, one of the most common considerations is how to keep the platform as up-to-date as possible without disrupting other workflows.

This is one of the reasons SaaS models have become so popular. Updates (not necessarily security-related) and maintenance are handled by the supplier, often without any disruption, allowing you to focus on your users.

Talk to us

If we can support you with designing or procuring a new platform, or you’d simply like to learn more, please get in touch.

Blogs Accessibility Apps consulting

3 positive habits for creating an accessible intranet or website

It is often assumed that an accessibility assessment (sometimes called an audit) is the first thing you should do when you want to make your website more accessible. If you want to know if your website conforms to a standard like the Web Content Accessibility Guidelines (WCAG), then an assessment is the way to do it, but if you want to move a little bit faster and start making changes that will make a real difference, there are 3 things you should get into the habit of doing.

Use an automated tool

It is important to understand that an automated tool cannot check for 100% of possible accessibility issues. For example, an automated tool can check if an image has a text description but not if the text description is appropriate or helpful to a human. Estimates very, but it is generally accepted that automated tools identify around 25% to 30% of possible accessibility issues. With that limitation firmly in mind, using an automated tool to check your website for accessibility is a useful thing to do. There are many to choose from including browser extensions like Wave, Tenon, Axe, or ARC Toolkit, Audit in Chrome dev tools, or external tools like Whether you’re working on a pattern, component or page, get into the habit of checking it with one of these tools – and fixing the issues it identifies. As mentioned before, you won’t catch everything, but you will be about 30% closer to where you want to be.

Use the W3C Easy Checks

The W3C has put together a set of Easy Checks to help you get started with accessibility testing. The Easy Checks are based on WCAG, but unlike WCAG there are just 10 things to check (there are 78 in WCAG 2.1).
  1. Page title
  2. Image text alternatives
  3. Headings
  4. Colour contrast
  5. Resizable text
  6. Keyboard access (including visible focus)
  7. Forms, labels, and errors
  8. Moving, flashing, or blinking content
  9. Multimedia alternatives
  10. Basic structure
With the same warning that comes with automated tools, these Easy Checks do not cover all aspects of accessibility. What they do cover is some of the things that are most helpful to people who find seeing, hearing, moving, or cognitive processing difficult. If you get into the habit of using these 10 Easy Checks in complement with automated testing, you’ll take another big step towards a more accessible website.

Use assistive technologies

Every platform and device now has a range of different assistive technologies that can be enabled or installed. This includes screen readers, magnification or zoom capability, and (although it is not strictly speaking an assistive technology) the keyboard.


Abandon your mouse or trackpad and make sure all functionality can be navigated to and operated with a keyboard. Make sure that:
  • All interactive elements can be navigated to using the Tab key (or arrow keys where appropriate)
  • All interactive elements can be activated with either the Enter or Space keys
  • All custom controls can be operated using the keyboard
  • The interactive element that has focus is clearly indicated, and that it is always possible to see which element currently has focus

Screen readers

Turn on the screen reader for the platform you’re using and make sure all content can be navigated to, understood and interacted with using a screen reader. Make sure that:
  • The screen reader tells the user what kind of content they’re dealing with (link, button, heading, checkbox, list etc).
  • When there is an implied visual structure (table, list, heading hierarchy etc.) the screen reader announces it correctly
  • When navigating a data table the screen reader announces the row and/or column header as focus moves between cells in the table
  • It’s possible to move between landmarks (like the header, main content area, navigation and footer)
  • The purpose of every link is clear when using the dialogue of all links on the page
  • All interactive elements can be navigated to using standard keyboard commands or screen reader keyboard commands
  • All interactive elements can be activated using either the Enter or Space keys
  • All custom controls are announced correctly and can be operated using the keyboard

Magnification and zoom

Make sure all content can be navigated to, understood and interacted with at maximum zoom. Make sure that:
  • All content can be viewed without any overlaps
  • Multi-column layouts reflow to a single column
  • It is not necessary to scroll both vertically and horizontally to view the same bit of content
  • Page features are consistently located across the website
If you get into the habit of enabling these assistive technologies, or setting aside your mouse in favour of your keyboard, you’ll find you quickly start to understand how different modes of interaction work. With that understanding you can take another, albeit cautious, step towards better accessibility. The caution is based on the fact that you are most likely not a full-time assistive technology or keyboard user, so your experiences will not match those of people who are, but like most things – the more often you do it, the better you get!
Blogs consulting Solutions

8 top tips for successful solutions workshops

In my role as CEO, I spend a large portion of my time coming up with solutions – this is actually the part of my job I enjoy most.

I have been involved in hundreds of workshops, some really successful ones and others, a complete disaster. Here are my basic rules when it comes to solutions workshops:

1) Get the right people in the room

The most important people to get in the room are:

  • those that will implement the solution

  • those that will use it

  • those that will have responsibility for its management

Keep the group as diverse as possible, you need introverts who don’t generally want to be in the workshops (on many occasions more than you need the extroverts). 

2) Engender a sense of challenge and/or fun

Make sure you set the tone early, before the meeting begins. Get people thinking about it as something other than a “meeting”.

Ideally, try to hold the workshops in places you wouldn’t hold regular meetings. Get better coffee and nicer biscuits – do whatever you can to make sure people see it as something different. You need their brains to be open and active from the start.

3) Frame the problem in the most generic form you can

The broader you frame the problem the better, however, it must frame the problem itself, not just some generic scenario.

“Workshops to discuss features to deal with GDPR” will only ever have one outcome, try something like “Workshop to discuss GDPR implications and impacts”. The 2nd option will stop the technical minded people taking over the workshop as it’s where non-technical people have the edge.

Key to framing the problem is setting out who runs the workshop. Set yourself up as the facilitator that asks pertinent questions to keep things on track but make sure the subject matter experts are leading through the session.

4) Recognise peoples natural tendencies and force them to think differently

I am the worst case for this. I naturally want to take over and get super excited – and need to be told to be quiet before it even starts!

Setup the workshop in a way that means the least controlling/vocal are heard right at the start and then asked for input throughout. Ask people who are subject matter experts about things that are completely unrelated to draw them out of their world. For example, ask the security expert what they think about the logo, do anything you can to draw people out of their natural tendencies.

5) Do not be afraid of arguments

I don’t mean friendly disagreements. If people are passionate that’s a great thing, but control it so it never gets personal.

Someone in the room will usually be sitting quietly listening to both sides, coming up with a middle ground that no one thought of.

Don’t be afraid to push people into opposite corners so that they really fight their case, just make sure you listen and summarise both sides in a positive manner that focuses on the key points of both, ideally in a way that shows they actually agree.

6) Keep bringing it back to the defined problem (no matter how much you want to go down another track)

The thing with working in this way is that it’s really easy to get excited with ideas and you have to allow exploration to avoid people shutting down. This is great because frankly, the group may see things you’re blind to, however, it’s extremely important to make sure you bring it back to the topic and ask them how their point, view or idea directly relates.

Do NOT chastise them for going off track, you want open minds to come up with innovative solutions.

7) Bring people back to the beginning and rerun through what you have discovered or agreed

Several times during the workshop, revisit the topics you have previously covered to see if they still hold through.

There are multiple reasons for this, firstly to verify the validity of what came before as frequently you will find that things that appear critical earlier in the conversation have become unnecessary or trivial because of later discussion.

However, it may also point out a major gap in the solution when viewed with the earlier thinking. Worst case, you keep everything aligned and reinforce the thinking so everyone leaves with the same understanding.

8) Remember to not have a detailed structure

What works in general meetings kills workshops. Project plans, detailed agendas are structured flows are all the death knell of great solution workshops.

I would highly recommend that you keep project managers out (unless it’s a pm related problem) until the end when they come in to understand what’s been agreed. If they are needed refer to point 4, keep them as quiet as is practical, they are naturally going to want tangibles when you want ideas and a different way of thinking.


Above all, the aim is to come out with a smile and with the feeling that your brain got a workout. If everyone feels like this, you’re probably 98% of the way to the solution you need.

Talk to us

Please feel free to get in touch with any questions or queries. We’d love to support you with your solutions workshops needs.
Blogs Accessibility Apps consulting

What is an accessibility audit and what does it include?

Accessibility audit overview

The Public Sector (Websites and Mobile Apps) Accessibility Regulations of 2018 require public sector organisations to make sure their websites, intranets and apps meet Level AA of the Web Content Accessibility Guidelines (WCAG) 2.1.

Key dates for meeting the regulations​

New public sector websites (published on or after 23 September 2018)by 23 September 2019
All other public sector websitesby 23 September 2020
Public sector mobile applicationsby 23 June 2021

Typically an assessment or audit is used to find out whether the standard has been met (or not), but what is an audit and what does it include?

An accessibility audit is an assessment of your website or app against a set of recognised guidelines, in this case WCAG 2.1 Level AA. The purpose of an audit is to verify that your website or app conforms to the guidelines or to tell you what you need to do if it does not.

Representative samples

WCAG 2.1 is divided into principles and guidelines and each guideline has a number of requirements known as Success Criteria (or SC for short). Each SC is assigned a different level: Level A, Level AA, or Level AAA. There are 30 Level A and 20 Level AA SC in WCAG 2.1. The basic premis of an audit is that your website or app is checked against all 50 of them, but there is an obvious problem with this – in most cases it would take too long and/or cost too much to do.

The recommended approach is to audit a sample of pages or screens instead. The idea is that the sample is representative of the whole; in other words it should include at least one example of each page or screen layout, each different type of content, and each different type of functionality.

Procurement tip: look for services that include a test plan so you know exactly what will be included in the audit and what won’t.

If the sample is chosen well it should contain at least one example of most (if not all) possible accessibility issues. Once one instance of an issue has been identified within the sample, the same solution can then be applied to all other instances of the same issue throughout the website or app.

Procurement tip: look for services that offer detailed solutions for each issue and ask to see examples so you know the level of detail provided is what you need to be successful.

Testing tools

An audit is essentially a manual process but tools help make the process more efficient. The important thing is to know when to use a tool and when to do something yourself.

There are tools that can help with checking for things like colour contrast, line height and spacing, or for mistakes in HTML that cause accessibility problems. Developer tools in Firefox, Chrome, Edge and Safari all have features for inspecting the accessibility properties of web page code, and there are tools for scanning and inspecting native apps on both Android and iOS.

Automated tools are useful for quickly testing a lot of pages, but they cannot test for all accessibility issues. Estimates vary, but it is generally thought that automated tools can identify around 30% of possible WCAG 2.1 issues. Those issues are worth monitoring and fixing of course, and the number of issues detected by an automated tool is often a good indication of how well the website is doing overall, so automated testing is certainly a worthwhile part of the process too.

Procurement tip: look for automated testing platforms that are open about what can and cannot be tested automatically.

Assistive tech testing

An audit should include testing with different assistive technologies and alternate input devices, but there is an important distinction to draw between expert testing and proper usability testing: expert testing is carried out by people who do it professionally, usability testing is carried out with people from your target audience (who tend not to be professional testers).

There is a time and a place for both expert testing and usability testing because they both deliver valuable insights. Like consulting with a Doctor and asking someone who completed a first aid course for their opinion, you’ll get two very different but nonetheless valuable responses.

Expert testing is typically included in an audit, whereas usability testing is a separate but complementary service that includes participant recruitment, professionally led test sessions, and results analysis and reporting.

Procurement tip: look for services that are clear about the differences between expert testing and usability testing.


Depending on whether the audit was carried out internaly or by a third party, the results will probably be presented in different ways.

The format isn’t really important though, what is important is that the information is presented in a way that is appropriate to the team who need to use it, that it’s apparent how well the website or app did in the audit, and that there is a clear path for fixing issues and ultimately to meeting the expected standard of accessibility.


There is one final step to an audit and that is making sure that all issues have been addressed, and that no new accessibility issues were introduced along the way. Like all updates, changes and fixes to a website or apps, regression testing for accessibility should be done before considering the task complete.

An audit is generally a single event. Although it’s possible to carry out iterative audits throughout the production lifecycle, it isn’t a good way to avoid accessibility issues in the first place. 

Empowering teams with the knowledge and skills they need to design and develop accessible websites and apps, and QA testers with the ability to test for accessibility, is by far the best investment you can make. That said, when legislation like the Public Sector Accessibility Regulations require that a particular standard of accessibility must be met, an accessibility audit is a robust and reliable way to find out whether your website or app succeeds or not.

We're here to help

We are passionate about supporting organisations to create a great experience for 100% of users. Invuse – the new name for Invotra Consulting – offers both accessibility reviews and accessibility audits.

Get in touch today to see how we can support you.