Why accessibility work and emissions reduction overlap
Making a site or app easier to use for people with disabilities often means reducing unnecessary visual clutter, relying on semantic HTML, and delivering content in ways that are predictable to assistive technology. Those same choices frequently reduce bytes sent, CPU work on devices, and server requests. The result is a dual benefit. Teams can improve inclusion while measurably lowering the energy and network resources required to deliver the experience.
How to frame a project so both goals are measurable
Start with two parallel acceptance criteria. The accessibility criterion should map to a concrete WCAG success criterion or a reproducible user test. The sustainability criterion should be a measurable change to page bytes, requests, CPU seconds, or a metric derived from real user measurement. Aligning the two criteria up front avoids trade offs that help one goal while harming the other.
Minimum data to collect before you change anything
Collect a representative sample of real user requests for the pages or flows you plan to change. Record total bytes transferred, number of requests, time to interactive, CPU time on the main thread if available, and the mix of device classes and network types in your audience. Run an automated accessibility baseline using a tool that reports WCAG mappings and then run a small manual test with one or two assistive technology users or experienced testers to capture gaps automated checks miss.
Example one: remove decorative images and provide semantic alternatives
What to change. Replace purely decorative raster images with CSS shapes or inline SVG where appropriate. When you must keep an image that conveys content include a concise alt attribute. For decorative images mark them as empty alt so assistive technology ignores them. Why it helps accessibility. Assistive technology users are not forced to navigate past irrelevant images and screen readers get meaningful content where it matters. Why it helps emissions. Removing or replacing bulk image files reduces bytes transferred and the CPU time spent decoding large bitmaps on devices.
Practical steps
- Audit your images and tag each as informative, functional, or decorative.
- For decorative images convert to CSS or inline vector graphics when possible.
- For informative images add succinct alt text and consider reducing resolution or using responsive images so smaller devices get smaller files.
Example two: prefer semantic controls over scripted widgets
What to change. Replace custom elements that rely on heavy scripting and ARIA to mimic native behavior with semantic HTML elements when they can provide equivalent functionality. Improve focus order and keyboard access using native focusable elements. Why it helps accessibility. Native controls behave predictably with assistive technology and require less bespoke work to make keyboard and screen reader friendly. Why it helps emissions. Removing large JavaScript widgets lowers script download sizes and runtime CPU work, which reduces client side energy use and sometimes server side telemetry or state traffic tied to those widgets.
Practical steps
Identify critical interactive components and attempt a minimal semantic implementation. Measure JavaScript payload size and main thread time before and after the replacement. Validate accessibility with keyboard only testing and with a screen reader. If a framework is required, implement progressive enhancement where the basic semantic control works without the full script bundle.
Example three: fonts and typography that balance readability and payload
What to change. Choose fonts and loading strategies that prioritize legibility while minimizing the number and size of webfont files. Use WOFF2 where supported and subset fonts to include only the glyphs your site needs. Consider a system font fallback strategy for critical text while lazily loading optional webfonts. Why it helps accessibility. Subsetting and choosing clear, readable fonts improve legibility for many users and reduce the risk of flash of invisible text for assistive technology. Why it helps emissions. Smaller font files mean less data to transfer and less decoding work on devices.
Practical steps
Audit which characters your content actually uses and produce a subset. Serve those as WOFF2 and keep a sensible fallback stack. Test with text scaling and high contrast modes to ensure legibility. Monitor font file transfer and decoding time using RUM to confirm improvements.
Example four: captions and transcripts for video with adaptive delivery
What to change. Provide accurate captions and transcripts for all audio content. Use adaptive streaming so the player selects a bitrate that matches the user connection and device. Do not force autoplay and ensure controls are keyboard accessible. Why it helps accessibility. Captions and transcripts make video content accessible to users with hearing loss and improve comprehension for users with cognitive disabilities. Why it helps emissions. Adaptive streaming and sensible defaults reduce unnecessary high bitrate delivery for users on small screens or slow networks. Avoiding autoplay prevents wasted downloads and client work for users who do not watch the media.
Practical steps
Author captions as text files and attach them as track files to the player. Offer a transcript page that search engines and assistive technology can index. Configure your video CDN or streaming setup to support multiple bitrates and test the player on representative devices to confirm lower bitrate selections when appropriate.
Example five: forms that reduce retries and round trips
What to change. Ensure every form input has a clear label, descriptive error messaging, and inline validation that runs client side to prevent avoidable full form resubmissions. Apply inputmode and autocomplete attributes where applicable to speed entry on mobile devices. Why it helps accessibility. Clear labels and helpful errors reduce cognitive load and make forms usable with screen readers. Why it helps emissions. Fewer failed submissions and fewer full page reloads reduce server requests and network traffic.
Practical steps
Instrument form flows to count submission attempts, validation errors, and successful submissions. Use that telemetry to prioritize the fields that cause the most retries. When adding client side validation ensure it does not block assistive technology and that server side validation is still present for safety.
How to measure the carbon side reliably without guessing
For digital services the core measurable signals are bytes transferred, requests, and device side CPU time. Convert those to energy and emissions using tools or frameworks chosen by your team. Use real user monitoring to capture distribution of networks and devices because the same bytes mean different energy on a low power phone on a cellular network than on a desktop over fiber. When reporting changes show the raw signals alongside any converted energy or emissions numbers and state the assumptions used for the conversion so results remain verifiable.
Suggested measurement workflow
- Collect RUM samples that include bytes transferred and device class.
- Aggregate by page or flow and compute median and 90th percentile for your signals.
- Use a consistent conversion method to translate bytes and CPU time into energy and emissions and document the conversion assumptions.
- Report accessibility test pass rates and the sustainability signal together so stakeholders see both impacts.
Rollout and validation considerations
Run changes behind feature flags and consider an experiment or phased rollout. Validate accessibility with automated checks and with manual testing that includes assistive technology users. For sustainability validate with RUM comparing the treated group to the control group. Monitor for regressions in either dimension and keep rollback criteria explicit. Avoid solutions that superficially lower bytes at the cost of making content inaccessible.
Governance and prioritization
Prioritize changes that are low cost to implement and that help both audiences. Examples include fixing missing alt attributes for meaningful images, replacing decorative images with CSS, subsetting fonts, improving form labels, and adding captions. Track wins in a shared backlog and require both an accessibility acceptance test and a sustainability metric update before closing a ticket.
Common pitfalls to avoid
Do not lazy load critical content that assistive technology needs to find. If you lazy load ensure it is still reachable by keyboard focus and discoverable by screen readers. Do not replace semantic markup with visually similar but non semantic markup purely to save bytes. Semantic HTML is often the cheapest path to accessibility and to lower runtime work. When reducing media quality for emissions make sure captions and transcripts remain accurate and available.
Next steps your team can take this week
Run an image audit for a critical page and identify decorative images to remove or replace. Subset one frequently used font and measure the change in transfer size. Pick a heavy interactive widget and prototype a semantic HTML version. For each change record both the accessibility validation and the before and after raw payload numbers so you can present factual results to stakeholders.
Practical improvements that help people and the planet are often the low hanging fruit most teams can implement quickly. By aligning acceptance criteria, measuring the right signals, and validating with real users you make progress that is verifiable and defensible.