For many software teams, especially web developers, accessibility is anextremely burdensome task. Many companies have written checks with anuncomfortable number of zeroes on them to get the job done. SprinklingARIAtagsall over your DOM to annotateelements with their purpose, and updating these as your DOM changes over time,is no small task, and makes your code more difficult to maintain. It’s notespecially surprising that many blind users are constantly frustrated whentrying to use the web.
How did SourceHut make such an accessible website, even in the face of thesetrials? In truth, even though accessibility is important to me, I haven’tworked especially hard to make SourceHut accessible — I have devoted nomore than three or four hours, in total, explicitly towards accessibility.Instead, SourceHut is accessible because the core principles of simplicity uponwhich it is built naturally lead to an accessible design. We’re here today toshare our thoughts so that you might apply the same principles to your ownwebsite.
First, consider the audience you’re designing for. Your users have a diverse setof abilities, and a varied approach to accessibility is necessarily required toaccommodate for them. Different users will have a different experience with yourwebsite. There are different levels of visual impairment — near- andfar-sighted users, colorblind users, and many degrees of vision impairment aheadof totally blind. Talking about accessibility might bring forth thoughts of thelatter group, but a lot of users with partial sight would also benefit if youput care into your visual design. There’s also other considerations than vision— for example, avoid high precision mouse actions for users with limitedmobility, and add subtitles to videos for the deaf and hard of hearing.
For general advice on web accessibility, I would start with the following:“trust the web browser”. Leave the page at its default font size and avoidusing custom fonts, preferring to use vague selections like “sans-serif” and“monospace”. Don’t mess about with the scroll wheel, don’t override defaultbehaviors on the right click and text selection. Don’t use JavaScript to createcustom input elements like text boxes, combo boxes, or scrollbars. The webbrowser will do all of these things for you — trust it to do a good job.
Remember that the browser is theuseragent, not thedeveloperagent. Bytrusting its defaults, you leave room for users to customize them, choosing alarger text size, a different font, and so on. The user is already comfortablewith the way their browser works, and you will fail to capture the subtlenuances of their user agent with your pretty imitations. When accurately usingthe mouse is a struggle, a user who has gotten used to using the arrow keys in a<select>box is faced with an unreasonable challenge when they encounter acustom drop-down that hasn’t implemented this behavior quite right.
Another case to be careful of is the use of color, contrast, and images. Alwaysmake sure that text the user is expected to read is sufficiently distinguishablefrom its background.Also avoid putting text over a variable background,such as a gradient or tiled background. Be conservative with your use of color— limit bright, visually attractive colors to one or two actionable itemson the page, or use them to draw special attention to timely notices, or to warnthe user of potentially dangerous actions like deleting data.
Try not to use a purely visual representation of information, such as an icon:these should always be paired with text. Such explanatory text shouldn’t require,for example, hovering to see it — a task which requires high mobility tohit a small target with the mouse, and holding it steady for long enough to makea tooltip appear. Also avoidmovinginformation around — animations andvisually complex state transitions. When adding images, always include an “alt”tag with a plain-English description of the image.
Do this exercise with me: cross your eyes, then close one eye. Through thisblurry view, can you still identify the major elements and action items on yourpage? Does anything demand too much or too little attention?
The “alt” tag reference a moment ago is the first time we’ve touched upon manyof the conventionally repeated wisdoms about “accessibility” on the web, oftenincluded because its value is intuitive and easy to implement. It’s no mistakethat we’ve covered little of such conventional wisdom so far: the typical userwho benefits from an accessible website is not completely blind, using a screenreader and taking advantage of your ARIA tags. The hard truth is that you justhave to make your website simpler and easier to use — for everyone.
But, it wouldn’t do to forget the users with screen readers in any case. Somegeneral advice for such users would be to make good use of semantic HTML, suchas<main>,<article>,<section>,<nav>, and so on; along with otherelements like<p>to mark paragraphs,<ul>and<ol>as appropriate to marklists of things,<quote>for, well, quotes, and so on. Screen readers caninterpret these to understand the layout of your page better and providecontextual clues to the user.
Prefer to organize your site’s informationlogically, rather thanspatially.A logical hierarchy of information is more intuitive if you have less visualawareness. Make sure your page is organized so that if read linearly, from startto finish, without CSS, it still makes sense. Avoid littering marketing garbage,superlatives, and ads for other parts of the site (or even ads outright)throughout your page, as skipping these is more difficult for a screen readerthan for the typical visitor. A good way of simulating the screen readerexperience is to view your page withLynx. Conveniently, Lynx does notsupport JavaScript. :wink:
This seems like a lot of effort to go to for accessibility! But, if you readclosely, this is mostly a list of things toavoiddoing. The SourceHutapproach side-steps many of these problems by focusing on simplicity. TheJavaScript-free interface is more accessible right out of the gate, and by notcramming too much into a single page it’s much easier to flow and organize in anaccessible way. This advice also leaks quite generally into the broader subjectofusability, which is no mistake: investing in accessibility makes yourservice better for everyone.
SourceHut also benefits from some design choices which extend beyond the web.For example, by focusing on email for discussions, patches, and code review,andinsisting on plain text, many blind users canchoose to completely side-step the web interface and interact with the servicesand users on it from the comfort of their mail client, using only Plain JaneText emails. Then, when they have questions, they can join our IRC chat room,a medium used exclusively to exchange short, plain-text messages, without thenightmare of navigating the Slack interface with a screen reader.
In summary, if you want to get accessible quick, a good start for your newwebsite might eschewnpm installin favor of this:
<!doctype html><meta charset="utf-8 /><title>My cool website!</title><main> <h1>My cool website</h1> <p>Welcome to my cool website!</main>
Which, in case you were unaware, is a completely valid HTML 5 document!