This is awesome to see. GOV.UK is going to be replacing their search functionality. The contract is estimated to be worth £900,000. The kicker’s below:
Work to replace GOV.UK’s search infrastructure is due to begin in early next year, with the initial phase of the project dedicated to identifying and evaluating products. Such assessments will be focus on “functional and non-functional requirements, based around user needs [and] include accessibility requirements… and progressive enhancement”.
When we old timers bemoan developers’ overreliance on JavaScript, we are coming at it from the perspective of folks who were building for the web before JavaScript was a server-side thing.
Some of us remember the early attempts at bringing JS to the server too. Remember Jaxer? JsExt? Rhino? Fun times.
Alice lays out a great roadmap for shifting accessibility earlier in your project lifecycle. Why, you ask?
Just like chocolate chips, accessibility is a key ingredient in your product pancake — and it’ll always taste best when it’s added to the mix at the beginning. It’s also more time- and cost-effective, as fixing a usability issue after the product has been released can cost up to 100 times more than earlier on in the development process.
I’m living this super deep dive into the UX of the quantity field in e-commerce.
How did I miss this? The gov.uk Service Manual recommends progressive enhancement for all their websites.
Using progressive enhancement means your users will be able to do what they need to do if any part of the stack fails. Building your service using progressive enhancement will:
- make your service more resilient
- mean your service’s most basic functionality will work and meet the core needs of the user
- improve accessibility by encouraging best practices like writing semantic markup
- help users with device or connectivity limitations to use your service
🥰
A clear and focused walkthrough of how to get started with performance budgets and then how to ramp up.
Five years old, but still incredibly relevant: An overview of common mistakes people make with ARIA, and how to fix them.
I talk a lot about the default behaviors of HTML buttons, but don’t tend to get into the weeds when it comes to keyboard interactions. Grab a machete and head on over to Adrian’s blog because he’s ready to take you there.
Excellent advice here:
[N]ext time you’re designing a new interface paradigm or chatting with an engineer, ask yourself about the risks involved in the known versus the unknown with the following questions.
- Does the new design use intuitive patterns that prioritize consistency?
- Are you in any way disregarding accessibility practices in favor of a feature or a visual direction?
- How tech-savvy are your users and can the newly-introduced experience be easily adopted by current and future, more-diverse audiences?
- Can and will your design decisions be validated through properly conducted user research and user testing?
Being mindful of these practices will help you guide decisions and ensure you don’t change things just because you can.
Some nice examples of how to use :has() in this one:
:not()li when hovering/focusing inside