🇲🇾
👾
🏀
🚲
🖌️
👟
💻
🖊️
🎙
🦊
🥑
🧗
🏳️🌈
Disclaimer
This talk is purely a sharing based off my personal experiences and I do not believe this represents the full picture of the situation in my region.
I am also by no means an expert on accessibility but I am trying my best to learn and get better at it.
To be honest, I'm fairly nervous about this talk, because not only is it a completely new talk I've never given before. But it is also about a topic that I'm nowhere as confident in my knowledge as compared to something like CSS or basketball.
I'm fairly certain there are folks in the audience who are way better at this than I am, and if there is anything I mention that you think is not correct, please let me know, I really want to get better at this.
a11y
There are a number of numeronyms relevant to the web, like i18n, for example, but I like the one for accessibility because it also looks like the word “ally”, which is just so apt, in my opinion.
My understanding of web accessibility is to make your websites or web applications usable by as many people as possible.
There is that inevitable association of accessibility as relevant only for folks with disabilities but it's much broader than that. I know from personal experience that all of us are simply temporarily abled.
You could fall ill or be injured. You could just happen to carrying something with one hand and trying to use your phone on the other. You might end up in a place with a bad connection. All of these circumstances should not block you from accessing information.
Web Accessibility Initiative (WAI)
Accessibility is essential for developers and organizations that want to create high quality websites and web tools, and not exclude people from using their products and services.
https://www.w3.org/WAI/
The World Wide Web Consortium (W3C) places a strong emphasis on making the web be accessible and usable by everyone regardless of their disabilities. And so, we have the Web Accessibility Initiative, which develops guidelines as international standards, support materials and resources with many different stakeholders.
I highly suggest visiting this site to get started on your accessibility learning journey.
Why isn't accessibility explicitly taught during the basics of web development? 🤔
I am a self-taught web developer. And the way I learned was through various free online courses like CodeAcademy and the like, plus a lot of trial and error. I started out copying and pasting code by viewing source, not even knowing what half the code did.
Even though I've read countless articles and heard from many experienced folks on different web development topics over the course of my career, I noticed accessibility made up a relatively small proportion of my daily consumption.
Thinking back on those online courses that I took, I can scarcely remember much mention of accessibility, and I do wonder why that is?
The 80-20 rule
The 80-20 rule is also known as the Pareto principle, which states that for many events, roughly 80% of the effects come from 20% of the causes.
What does this have to do with accessibility, you may be wondering? This ties back to my previous thought on why accessibility part of the standard learn to web curriculum because there are numerous low-hanging fruit level things that are not overly complicated to implement. These things are perfect for folks just starting out with web development.
And if we took care of those things throughout the course of the project, instead of as one big scary accessibility task, you'd barely feel the weight of any extra effort at all.
Some of what I'm covering may sound like no-brainers, but I've encountered numerous projects that have missed them out, to an extent that I've stopped being surprised.
Web Accessibility Laws in Asia
This is some information on web accessibility laws in Asia I managed to dig up, most of it is from the W3C site directly but if you notice, they are mostly recommendations or guidelines. The only scope where accessibility is mandatory is for government sites.
So I don't think it's comes as a surprise to see folks here who don't see accessibility as something important. And based on my personal experience working for local companies, management tends to be fairly top-down, sometimes you might get feature requests that really don't make sense but because the CEO said so…
I'm not saying that all local companies ignore accessibility, but I do feel the lack of legislative consequence does have an impact on how organisations perceive its importance.
But what can I do?
Use your own best judgement
Before we get into things, I do want to stress the importance of using your best judgement on the content you're trying to present. If you're planning to use an animated 3D stacked pie chart, consider including an accessible data table that can express the same thing.
But if you're trying to present say a 3D CSS art work collection, then it doesn't make sense to insist every art piece is perfectly accessible to visually impaired folks since the medium is completely visual.
Level 1: No one can tell you're doing it
Depending on the type of environment you're in, I would say there are different levels of what you can do, how much you can push back on certain things and so on.
So let's start from the stuff that you almost definitely can get away with. I know it's slightly depressing that I'm framing accessibility in this manner, but I accept my reality and I'm merely sharing my thoughts based on that.
Page titles
Instead of…
Welcome to the home of the fluffiest musicians in the universe the Fluffy Philharmonic
Fluffy Philharmonic - Musicians
Fluffy Philharmonic | Life at FP
Try doing…
Fluffy Philharmonic home page
Musicians - Fluffy Philharmonic
Life at FP | Fluffy Philharmonic
I consider actions you can take on an individual capacity and are relatively low effort, things you can get away with, like page titles. Okay, maybe this wasn't the best first example, and page titles are important for SEO as well.
I don't actually recall seeing any websites without A page title, probably because I wouldn't have found it on Google at all. But I have encountered pages that don't have proper page titles when navigating within the site. Like, the page title remains unchanged as the site name or something.
So this is definitely something to check, because it is easily missed out. The best practice is to front-load important information first.
I don't think people intentionally miss this out, but with hardly anyone writing meta tags by hand anymore, this is sort of a common issue, especially when we forget to setup our templates properly.
Image text alternatives (alt text)
Every image must have an alt attribute
If the image conveys useful information, then it needs alt text.
If the image is purely decorative, set the alt attribute to empty.
Context is everything
Text should be functional and provide an equivalent user experience, not necessarily describe the image.
Reference: WebAIM alternative text guidelines
I personally took a while before I got the hang of this. I would love to say that I knew about best practices from day 1 that is clearly a bold-faced lie. No, no, no, I've done terrible things. Like setting the alt text to “image3̦”. I have since been trying to redeem myself.
All jokes aside, this is really a bit of an art rather than a strict science. And the examples from the W3C as well as WebAIM really helped me grasp the guidelines. First of all, every image must have the alt attribute, even if its empty, it must be there.
How the alt text is written does depend on the context in which the image appears and the intended content of the image.
Even though Viola the red panda had played the violin for many years, she wasn't exactly passionate about it. But the first time she tried the viola, she finally knew what love was.
Pick the appropriate option:
"Image of Viola the red panda"
"Viola, the red panda who fell in love with the viola"
An empty alt attribute is enough
"Viola, the red panda" ✅
Option 4 would likely be the best alternative text in this instance. Option 1 unnecessarily describes the image as an image. Option 2 provides extra information that is not presented directly in the image and it is also redundant with content presented later within the text. Option 3 (no alt attribute) is not appropriate because the image conveys content that is not directly presented in the surrounding context. Even though the surrounding text does indicate that it's referring to Viola the red panda, visual users can tell this directly from the content of the image - so if the image conveys content, it should be given alternative text.
Viola, the red panda
Even though Viola the red panda had played the violin for many years, she wasn't exactly passionate about it. But the first time she tried the viola, she finally knew what love was.
Pick the appropriate option:
"Viola, the red panda"
An empty alt attribute is enough ✅
"Image"
No alt attribute is required
In this case, the content of the image is presented within the surrounding content, so Option 2 (alt="") is the best choice. Option 1 would be redundant. Option 3 provides extraneous and useless information. Option 4 (no alt attribute) is never the right choice - every image must have an alt attribute.
Use the lang attribute
Declare the document language using the lang attribute on the html element
Indicate if there are language changes with the lang attribute on specific elements
<html lang="en">The fourth animal in the Chinese Zodiac is Rabbit (兔子 ).
I had previously dug a little bit more than usual into this because someone once mentioned to me that CSS had nothing to do with internationalisation. No.
And because I'm a terrible vindictive person, I proceeded to write a 2,500 word blog post about it, and made it into a talk. Yes, I can be passive aggressive like that.
But anyway, I find that the lang attribute sometimes can get overlooked and most times, mixed language content does not get marked up appropriately.
Aside from the fact that there are SEO benefits to setting the language of your website, and that services like Google Translate can and will make use of this attribute. I will instead let this clip speak for itself. Oh no, an inadvertently bad joke.
Use semantic mark-up (1/3)
The <div> element is not a magical hammer
Reference: HTML elements reference 🧡
This is sort of a wide-ranging tip because as you dig into the Web Content Accessibility Guidelines (WCAG), there is a lot to learn and cover to hit triple AAA, which is the best target. But I'm not even going there yet.
Standard HTML controls for user interface elements already meet basic WCAG success criterion when used according to specification. Browsers have a lot of accessibility features built in, the work has already been done for you. All you need to do is use the appropriate element.
There are semantic elements for lots of things, from addresses to keyboard inputs to maps and time. My suggestion is, before you create that next div, think about the content you want to put in it, and check if there's a semantic element for that.
Use semantic mark-up (2/3)
Buttons and links have different semantic meaning
Submit Use buttons for actions
CSS lets you style them both however you want
Reference: A Complete Guide to Links and Buttons
A fairly good check of when you want to use a button and when you want to use a link is to ask, what happens when your user clicks? If the click triggers an action, go for a button. If the click brings them to somewhere else, go for a link.
This distinction can have major implications for usability. Links must have a non-empty href attribute for keyboard users to access them. But the biggest problem is when developers create links that go nowhere.
For example, drop-down menus that activate on hover only. Easier to show on CodePen.
And besides, as developers, we have the power of CSS to let us style either element however we like. I recommend this very comprehensive article on links and buttons from CSS tricks.
Use semantic mark-up (3/3)
Keyboard accessibility by default
Interaction
Keystrokes
Notes
Navigate to most elements
Tab Shift + Tab - navigate backwardKeyboard focus indicators must be present.
Link
Enter
Button
Enter or Spacebar Ensure elements with ARIA role="button" can be activated with both key commands.
Checkbox
Spacebar - check/uncheck a checkboxCheckboxes should be used when one or more option can be selected.
Radio buttons
↑ / ↓ or ← / → - select an option.Radio buttons should be used when only one option from a group can be selected.
Select (dropdown) menu
↑ / ↓ - navigate between menu optionsSpacebar - expandYou can also filter by typing letters, but this behavior varies by
Autocomplete
Type to begin filtering↑ / ↓ - navigate to an optionEnter - select an option
Link: Form elements
This is only part of the testing checklist on the WebAIM site that outlines what is expected for keyboard interactions but you know what? Using semantic HTML elements gives you almost all of it out the box.
Sharing another personal anecdote here, a very extreme case imo, so not sure if anyone can relate, but I've seen code that went through a whole lot of trouble trying to recreate the behaviour of a text input on an empty div element.
Even though my first thought was, wow, this person doesn't know the input element exists, the amount of code written made me aware of how much the browser takes care of already as long as we do the minimal effort of using semantic elements.
Level 2: Get designers/writers involved
If you are in an environment where you can make content/design decisions autonomously, that's great. But I find it is more common to have full-time designers and sometimes content writers you work with.
All the previous tips were almost visually invisible, but things like colour contrast, text sizes, form labels and so on are probably things you would want to discuss with the designers on your team.
If your designers are not familiar with how browsers work, I really believe that the time and patience developers take to explain reasons why a certain design might not be the best idea is worth it.
Resize text
Don't break zooming
Let users control text size
Reference: Accessibility in browsers: zoom level vs. font size
For a while I had been told not to use fixed font sizes because it would break zoom on browsers. But I noticed that even when I set a fixed font size trying to zoom with the browser still grew my text as expected.
Browsers implemented something called proportional scaling years ago, and the simplistic explanation is that it makes CSS pixels larger, hence the viewport smaller allowing media queries to trigger.
But there is also something called text scaling, which only works on websites that define font sizes and maybe some other elements with relative units, like rems.
Users have the option to set their default font size from the browser settings, so it is still a good idea to size things with relative units to respect your user's default choices.
Write meaningful link text
“Click here” isn't very helpful
Write link text so that it describes the content of the link target
The recommended practice is to write the link text in a way that users have a fairly good idea of where the link will lead them BEFORE they click the link. In other words, the purpose of the link can be determined from the link text alone, or from the link text together with the text of the enclosing sentence.
Use spacing and proper sectioning
Negative space and proximity can help make relationships between content more apparent.
Ties back to use of semantic mark-up for headings and content.
Content should be easy to scan.
This would be less of a problem with a designer around, I'm assuming, but let's not assume. The point is, Gestalt Principles, which describe how humans group similar elements, recognise patterns and simplify complex images when we perceive objects, do make a practical difference. And we have the CSS to achieve this.
Colour issues (1/2)
Provide enough contrast between text and background
Instead of…
This is a pretty unreadable combination. I mean, sure I'm using the browser default sans-serif, and the content is not particularly interesting, but still. I'm giving everyone the access to read my shitty content and judge for themselves.
Try doing…
Clearly a better combination. It didn't make the content any better, I'm still using the browser default sans-serif, and the content has not improved at all, but still. I'm giving everyone the access to read my shitty content and judge for themselves.
One of my pet peeves is light gray text on a light background. What I try to tell the designers is that no matter how pretty your font is, it doesn't matter if nobody can read the text anyway.
And now is probably a good time to talk about the improved accessibility features in browsers' Devtools! I love DevTools. Can't live without them. Both Firefox and Chrome have features that show the contrast ratio of elements on the page.
What's important to note is that sometimes the number alone is not enough, as demonstrated by this tweet from Adam Argyle.
Colour issues (2/2)
Colour alone is not enough to convey information
Also, even though colour is very helpful in conveying information, it should not be used as the only way. This is a relatively common user interface where we have forms with a mix of mandatory and optional fields.
Here is also where DevTools can come in handy for a quick visual proof of colour issues. You can simulate a variety of conditions from the accessibility tools natively.
Make interactive elements obvious
Links and buttons should have distinct styles from the rest of the text
Keep them consistent throughout the site
It's fairly common to have customised link styles and hover styles but there are still a couple of things to note. Related to the previous point about colour, it would be better to have something extra like an underline to indicate the presence of a link.
This is why I suggest developing a good working relationship with your designers and constantly keep them updated about browser behaviours, what is possible with new CSS and so on. And take the opportunity to slowly share your knowledge about accessibility.
Anyway, links. We can do lots of fun stuff with CSS, so go ahead and be as creative as you like, but don't forget about focus states.
The outline property and the border property are fairly similar except that outlines never take up space, since they are drawn outside the element's content. And they don't necessarily have to be rectangular, but they almost always are.
Form elements must have labels
Placeholder text is not a substitute for labels
Make sure the association between the field and label is clear
All input fields should have a descriptive label adjacent to the field. Exactly where can depend on the language direction as well as the type of input in question, but the Gestalt Principles mentioned earlier still apply.
The space between the labels and the fields should be smaller than the space between the fields themselves so it is obvious what the label is labelling.
Why so hard…?
I've tried to cover the most basic, generally Level A (according to WCAG standards) items today that you can apply even if you are working in an environment which can be challenging to push back on top-down decisions.
In a more ideal situation, and if you feel empowered enough, it is definitely worth the time and effort to try to share your knowledge of accessibility with your team and explain how taking care of these things result in usability improvements for everyone.
It will also be less hard to take care of these things during the start of the project as opposed to having it tacked on at the end after all the pages and content have been built out.
People I've learned from 🥰
And many more folks who share their knowledge about accessibility…
