💾 Archived View for wilw.capsule.town › log › 2021-09-22-accessibility-for-everyone.gmi captured on 2023-07-10 at 13:50:28. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-04-19)
-=-=-=-=-=-=-
For many developers, the notion of _adding_ accessibility features - such as image `alt` text attributes to web page images and integrations with host usability enhancements, such as screen-zoom and text-to-speech - might feel like a chore. Especially for those still in the startup or "do things that don't scale" phase.
It should no longer be about "adding" accessibility features any more than one these days "adds" a mobile-friendly version of their site (long-surpassed by responsive design and mobile-first pricinples) or even "adds" a button to perform a specific task. Accessibility features are a core part of any product, and should factor into the software development process right through from requirement engineering through to planning, design, implementation, and testing.
Avoiding accessibility requirements is not only exclusionary and selfish; it results in sub-standard software. If you're developing an MVP solution or software purely to be tested, by ignoring accessibility needs you automatically exclude whole segments of your audience, whose valuable insights and inputs at the important early or late QA phases will never make it into production before it's too late.
It's been well-known [1] for a while that diversity in the software development process enhances the end product and creates a better and more well-rounded solution for everyone.
On this point, the other thing about accessibility features is that they improve usability _for all_, and gives everyone more freedom. Some people rely on the features and supporting technology more than others, but we can all take advantage of it. There is no downside to its inclusion in software development. As well as improving the experience for disabled people, accessibility factors can enhance usability for those using smaller screens, text-based browsers, or people on slow connections.
Going back to the example near the start of this post, one advantage of `alt` text attributes, and semantic markup, are that they empower screen readers to perform their job more accurately and helpfully to their user. Technology exists to help us, and companies like Apple and Amazon take advantage of this now to announce messages to us via AirPods whilst out on a run [2] and to tell us about our day ahead [3] perhaps whilst driving to work - amongst a growing array of usability and quality-of-life features.
It's not just big tech that are expected to fulfil these needs (though we can learn from their examples). Many modern and popular frameworks today - such as the Create React App [4] project - include code linting rules that help to enforce various accessibility traits for content like images and emoji. Additionally, UI component libraries, such as Bootstrap [5], automatically include various `aria` attributes [6] in their components. This makes it easy for early-stage startups - or one-person teams - to enhance usability.
You yourself may not _need_ to use accessibility features right now, but it's likely you will at some stage in your life - especially as interfaces continue to develop in complexity through to enhanced gestures, spatial environments, and AR and VR. It's up to all of us to encourage and practise accessibility-focused development so that it remains a growing priority in the decades to come.
My website is by no means perfect and should not (yet!) be an example to follow. However I continue to learn more about the space and endeavour to maximise usability and accessibility through factors like `alt` text, simple interfaces, using plain and semantic markup, improved reader mode optimisation, and by making all blog content available via RSS.