Transcript#

This transcript was generated automatically and may contain errors.

Hello, Sarah and I are statisticians working in the UK Government. We lead on the development of the ShinyGovStyle R package and we want to share a bit about our experience of how we've used it to help us and others across the UK build production-ready RShiny apps.

During the pandemic, we saw a huge surge in people wanting more data and wanting it now. With RShiny, we found we were able to build dashboards within hours instead of requiring a full software engineering team that could have taken weeks or months to build. Naturally, as all these dashboards were then appearing, we then got a lot of pressure to be able to publish these as fast as we were making them.

So, we ended up in this position. Statisticians standing there, fresh RShiny app in hand, knocking on the door of our IT teams. At this point, we found lots of red tape and just generally we were lost in a world quite far outside of our comfort zone as R developers.

We quickly realised we're not as irresistible as puss in boots, so we had to take a different approach. That's where we picked up the development of the Shiny GovStyle package. We've used this to pull in the UK government design system into RShiny itself.

Three main challenges

There are three main challenges we want to talk about today. The first one is accessibility. We want to make sure our apps work for all users and work for assistive technologies such as voice activation and screen readers.

Trustworthiness. This is all about getting our IT teams to trust that we can build reliable apps and getting our end users to trust the apps that we publish as well.

Last but not least, as package developers, we've been battling with usefulness. Ensuring that we can maximise the value from the time we spend on the package and also understand our role in the wider government development landscape as well.

Accessibility

For accessibility, in the UK, all public sector services must follow the Web Content Accessibility Guidelines, or WCAG for short. As our developers, we've had to show that we understand how to develop accessible web applications. Otherwise, we're simply not allowed to publish.

First thing, we found that we weren't really aware of the range or prevalence of accessibility needs out there. Like many people, we often tested our dashboards ourselves and then thought, that was that. If it works for me, it's going to work for everyone else. This was quite a big blind spot.

I've got a few stats from the World Health Organisation and other bodies just to illustrate the prevalence a little bit more. If you imagine you're in an average room of 10 adults, 8 out of 10 people in that room will have a vision impairment. This could be full blindness, low or poor vision, or other conditions such as cataracts.

3 out of 10 people in that room will have some form of dexterity impairment. So, fine motor skills and hand-eye coordination will be affected. Another 3 people in that room will only ever access the internet using their phone.

These numbers are huge portions of the population and not all of them will use your Shiny app. But if you're publishing publicly or you work in an organisation of hundreds or even thousands of users, it's far more likely than you think that these users will need to use your Shiny app.

I just want to take a step back for a second and ask a very simple question. How do you brush your teeth?

In the UK, over 2 in 3 adults now use an electric toothbrush. And even if you don't use one personally, you can see why they would. They help you do more but with less effort. So, what's not to like? They were originally invented in 1927 just to assist people with limited motor skills so they could brush their teeth. And it wasn't until the 60s that manufacturers developed more mainstream models and later on as they gradually gained popularity.

And I find this is a really nice example of just how designing something with accessibility in mind to make a fairly common everyday task easier has actually made it easier for everyone else in the population as well.

So, hopefully it shows, even if you were watching that earlier bit and thought, not enough people use my Shiny app, don't need to worry about this. Actually, all you're doing there is cheating yourself of the benefits of designing with accessibility in mind.

Actually, all you're doing there is cheating yourself of the benefits of designing with accessibility in mind.

Styling and colour contrast

So, I've got a really simple example here of the difference that styling and colours can make. So, this first clip, I'm going to demo a very basic Shiny app with no additional styling. And I want you to see, can you see what part of the dropdown a user is focused on?

At first, with a cursor, you can kind of look across and see where the cursor is in relation to the dropdown. If I navigate with a keyboard now, can you still follow where the user is focusing? I have fairly good vision. I am still struggling just at a small distance from a screen to see where this is. It's a very light green, grey shading there.

So, this is a dropdown that's just got three options. But imagine if you had 33 options, how easily you could lose your place and where you are. That's a huge difference.

So, within our package, we've added our own functions and we add in the standard styling that has high contrast. So, if I play this next example, you can see how much clearer it is to spot where the user is focusing at any given point in time. And having a strong contrast for interactive elements like this or text is hugely important. As a simple rule, you generally want to aim for at least a 3 to 1 contrast ratio.

And I've got a QR code and link here if you want to go and check off your own styling because not everyone's going to want to use the UK government branding. You'll all have your own themes and branding yourselves and organizations. So, you can go off, you can check your own colors and just make sure you have enough contrast in places like this.

Screen reader experience

Next, I want to give you a bit of a flavor of what it's like for a screen reader user when they interact with a website. So, for this one, I want you to think about what this site is for. Can you tell what this site is for just from what the screen reader tells you?

Nice and clear, right? This is what the app itself looks like.

One of the first things that was a problem here is there was no title set. So, it just read out the raw URL to start with. So, immediately, you're lacking a bit of context. As you went through the navigation links, you said, click here, click here, click here. You couldn't really tell what they were going for, where they'd take you to. There were some icons in there that might have given you clues, but they're not all obviously linked or clear.

As it came down the page, there was no heading. So, you just went straight to the image. And also, with the image, it had alt text in, but that alt text, all it did was tell you it was an image with information. So, it just teased you. And really, that might as well have not been there at all. You just couldn't get any of this information from that.

I've got another app now which uses our ShinyGov style package, and I want you to see if from the screen reader readout you can actually understand where you are in the app.

So, both of these examples have the screen reader set fairly slow for the user to understand. First thing I think you'll notice with this one is there was a clear title marked. Admittedly, it struggled a little bit with empty cars. I think they called it Mount Cars instead. But it gives you a little bit of context straightaway as to where you are, what the page is that you're on.

As we went down, there was a skip to main content link which I'll show you in the next slide when we see what the website looked like. That allowed me with a keyboard just to jump to the main content, get straight to the text, explaining what the website was. Next, I then reverse tabbed back into the navigation links. As soon as you went into them, you could hear you were in a contents list. There were four links there. And each of the links told me what I'd be tabbing into, whether that was the charts or the tables or anything like that.

So, as a user, hopefully you can see now how big of a difference you can make to someone who's using a screen reader.

This is what that app looked like. I'm just going to press play here so you can see the skip link itself. You might have seen these on other websites. And they're really, really helpful for keyboard users. If you try and navigate just using your keyboard, you'll soon start to see a lot of websites have a lot of links and various stuff near the top of navigation that is usually helpful just to skip straight to the content.

And also on this, it's just a little bit cleaner, a little bit clearer. Even looking at it, you've got clear content. You can see the text cleanly. There's that title across the top. You know what you're looking at.

On this slide, I've got a screenshot from NVDA, non-visual desktop access, which is the free screen reader I was using for the last couple of examples. And you can see how the first layout of this, only the links are listed. And that's because it's quite common for users just to navigate through a site using the links alone. If you think back to the first example and you heard the content read out, all the links were saying, click here, click here, click here. There had no real context to what they were doing. And for users using assistive technology like this, this has a massive impact because of the way they tend to try and navigate about.

So imagine this screenshot, but it just said, click here, all the way through. How on earth would you know where you were and what the structure of the site was to be able to navigate it? In practice, you probably wouldn't, and you'd just give up.

And this is one of the things that we've done within the package. So to tackle this issue, we've built our own external link function. So we've made sure that for developers themselves, this function's pretty much the same as just using the tags from Shiny or HTML tools. You put your href in, you put your link text in. But behind the scenes, we do some accessibility checks to help link text be a bit more useful.

So the first thing we've done is curated our own list or data set within the package of bad and non-descriptive link text. Examples like click here are the common ones. And if that's matched within the link text argument, we just give an error and tell the developer to be more descriptive. We also give a warning if link text is less than seven characters long because one-word links are less descriptive generally. Plus, for users with mobility impairments, single words are actually quite hard to click on. They're not a very big target area.

And last but not least in this, we've also added a hidden screen reader message that's not visual on the site all the time. It's an option to toggle that. But behind the scenes, it'll just add opens in a new tab for any external links that take you to a different site. Even as a visual user, opening a new tab can be quite disorientating sometimes. But if you're using a screen reader, you can't see you're suddenly in a new tab when you browse on a completely different site. So this makes a huge impact just warning them that that's what's going to happen.

It's a very simple function in the small part of the package that we've done, but it's a really nice example of how we've been able to pull together our knowledge that we've built up through this process and put those into easy-to-use functions to allow other developers to build their shiny apps just as quickly but with nice guardrails around them to help keep them accessible.

So now I'm going to pass over to Sarah for the next section.

Trustworthiness

In an age where most people have access to the internet and there are swathes of information out there, how do they know what to trust? And similarly, at a time where the information we release is heavily scrutinized and new cuts of data are requested frequently, how can we convince our digital and IT colleagues to let us publish shiny apps that statisticians have created when a great deal of risk is involved?

To illustrate this issue, which of these would you trust? On the left hand here, we've got this cat facts website which may or may not send you some spam text messages, and on the right hand side, we've got the National Geographic page which clearly lists out some facts about cats. The stakes here are clearly lower when we're trying to find out cat facts, but for the general public, how do they know what they can trust for schools, the economy or the environment?

People are aware of misinformation on the web but we need to make it clear to our users that our statistics are trustworthy and can be relied upon. We also need to closely work with security and IT experts in our departments to clear any external outputs, but how can we get their buy-in if our pages look more like catfacts.org and less like National Geographic?

This is where gov.uk design comes in. The simple and clean design of gov.uk gives users trust in our outputs and presents them with a familiar layout. The design's been really extensively tested and developed with user researchers, making sure that it works for users with all different types of accessibility needs. And this CSS is published online for developers to use on the gov.uk design system website.

It's helpfully split out into components like you can see with the button here. It tells developers when they should use the component, how it works, and has links to the underlying HTML. We can then use this CSS file, make some minor tweaks, and then use the attached dependencies call from HTML tools to attach this static CSS styling to our shiny widgets in shiny-gov-style.

To demonstrate the impact of this, take a look at an app with and without the shiny-gov-style styling attached. So this is our showcase example app and you can see that without the shiny-gov-style styling, the radio buttons are stacked on top of each other, we've got quite messy contents, and the cookies and the header bar all look quite cluttered. As soon as we've attached the CSS styling with that attached dependencies call, this neatens it up and brings it into the gov.uk design.

This results in a page that's powered by shiny but looks and feels like a real gov.uk page. So on the left here in this example, I've got a real gov.uk service and this is civil service jobs. And on the right hand side, I've mocked this up using our shiny-gov-style package. You'll see the design elements are really similar from the heading bars and the cookies to the beta banner and the email and password entry.

And there's a really clear link to accessibility here. So being able to navigate pages with a similar layout, it's really important for those who can't visually see a screen. Like we saw in Cam's demo earlier, it does take a while to orient yourself in a new and unfamiliar page layout. So using the gov.uk layout benefits both users with accessibility needs and those without.

And this clear similarity helps us gain trust with our stakeholders who we need to convince to let us release information this way and our users who need to be able to rely on our outputs. IT and digital know that the elements in the page meet accessibility guidelines, although they'll still need to check this on a case-by-case basis to make sure that analysts are using these appropriately. And users of apps, whether they can visually see the page or not will be familiar with this design, building trust in our outputs.

Usefulness

The last barrier that we faced was something that might be familiar to all package developers, and that is usefulness. So how do we keep the package useful to our users without making unnecessary work for ourselves? Our package is developed and maintained by a team of volunteers across lots of different departments in UK sort of service. So utilizing their resource effectively is really important. Our GitHub issue log helps us keep on top of what users are asking for, what bugs have been raised, and which volunteer is working on it.

One example of a useful feature that we've recently added to the package is styled reactable tables to something that a user had requested. So out of the box, these aren't always suitable for GitHub.UK dashboards. You might be able to see there's a very small sorting arrow that appears at the top, but these are really hard to make out with visual impairments. We decided it was worth our time to add new CSS for reactables to the standard Gov.UK design as it is a fairly niche use for analysts building R Shiny dashboards and unlikely to have any replication across government.

The result of this is a Gov-styled reactable table. So we took a lot of elements from the current static table in the top left, which was designed on the Gov.UK design system. So we don't want to diverge too far from this user research design, and we want to keep that trust with our users. So this simply adds in things like accessible sorting with the blue bars you can see at the top and the bottom of the column headers and accessible hover overs with that yellow highlight so that it's really clear what a user is focusing on.

An example of an issue that we decided not to fix is dark mode. So this is a much wider government issue, and it's been raised with the design team for many years. They've been looking at tackling it in the long run, and we don't just want to spin up a version of it that analysts will come to use, which we then need to change to fit with wider government branding later on. So building 50 different versions of dark mode can make it really hard to keep that trust with users that we mentioned earlier across all services.

Dark mode's been an ongoing conversation since 2018. You can see when this person raised it. And in GovDesign, there are a lot of changes involved that are much bigger than our little package with a fairly small use case for analytical dashboards. This thread shows a lot of people going off and building their own versions, each different from each other, and we don't want to be adding to this list of things to consolidate once a fix is finally in.

So there's a real challenge here in deciding where best to spend our time as package developers to add the most value. And the solution's been working really closely with both of our users and the wider government to understand how the package is being used and when wider changes might affect it.

Impact and conclusion

Thanks to ShinyGovStyle, analysts all the way across government have now been able to easily publish dashboards for both external and internal use. The package has lowered the barrier for entry to publishing dashboards for many analysts, and it's now used in a range of departments from education and tax, where Cam and I work, to health and the environment. So no more begging our IT colleagues to let us publish these dashboards thanks to ShinyGovStyle.

The package continues to be maintained by a team of volunteers across government who are all really passionate about making sure that our apps and services are accessible to everybody. If you want to find out more or have a little poke around our package, please scan this QR code, which will take us to the documentation for ShinyGovStyle. From there, that links out to our source code on GitHub, and you can contact either me or Cam through there too. Thanks for your time today.