As a front-end developer, it’s sometimes difficult to place yourself in a company or even in a project. Principles can help frame what we do and give us a focus.

I loved the framing of front-end from ‘Why you should hire a Frontend developer’

Ultimately the job of a frontend developer is to make people’s lives better, or at least not make it worse.
– Charlie Owen

The web we choose to build needs to reflect this, how do we not create barriers for people who want to use our websites or services?

I reflected on this with another DWP front-end developer James Gordon when we were talking about front-end principles.

We broadly split it down into accessible, agnostic, robust, performant, and secure.

This followed a similar pattern to Clearleft’s excellent “Front-end design principles” from 2013. Allowing us to group our motivations into two categories: benefits for the user, and benefits for the developers.

With each of those principles, there is a chance we create barriers for users that would stop them from accessing what we have produced.

Often when we have barriers like the ones below it points to a lack of inclusive design.

These principles align with the GDS Service Standard and help ‘Make sure everyone can use the service’ and fits into some of the elements of DDaT for frontend developers.

• Accessible — Use semantic html, and make sure we meet the WCAG 2.1 AA standard as a minimum and it works with assisted technologies (this sits along side the DWP Accessibility Manual)
• Agnostic — Build mobile first and make it work across a range of devices, and user contexts
• Robust — Use progressive enhancement, make sure what we build fails gracefully
• Performant — Optimise our code/assets for the best possible performance across a range of networks and devices
• Secure — Create a secure service which protects users’ privacy. Use strict content security policies and guard against common OWASP attacks.

These are a starting point that will be iterated further. They also need to be put alongside design standards.

In practice when we don’t think about our users we ultimately create barriers and fail our users.

Accessible

Probably the most poignant example of this is the issues with the Australian Federal Government Covid vaccine finder website. This flags that people who are blind or with low-vision can’t use the website.

We have potentially excluded some of the most vulnerable by building a none accessible website.

Agnostic

It is a similar case when we talk about other parts of the web we build.

When we build non-agnostic websites, we create barriers for people who don’t have access, a good example of this is when we only test our websites on high-end large-screen smartphones. We need to sure it works across a range of platforms and devices.

Robust

With websites that are not robust, when we remove JavaScript, or CSS, do we still have a working website?

What if a user can’t login? What experience can we give them?

“How well does it fail?” sticks with me from Jeremy Keith from a technical and design implementation.

Performant

From a performance point of view, we need to think about how our service works on slow network connections and how much data we are sending to the user and optimised as much as possible.

25mb of images may not sound like a lot, but if I am on a 500mb data contract, and I’ve taken up 10% of my data allowance because you’ve not optimised or cached your images, it becomes more of an issue.

Secure

Security is probably one of the most difficult ones to talk about, I recently finished a stint working on the Apply for Child Maintenance service where more than half of people who apply tell us that they or their children have been victims of abuse or harassment. A lack of security for these people may mean a compromise of identity.

The ‘Hide this page’ is a perfect example of cross-role and cross-team collaboration to help make sure our users feel safe and secure online to use a service.

With all these principles, I am not the user.

I don’t have access needs (yet) or a limited data plan, but through standards, collaborating with designers and across Government, testing, and user research I can get context and help make the web we choose to build more inclusive.