Being a daily a11y
How the nitty gritty of accessibility makes me a better designer
In the midst of the Summer of COVID, I set upon a project that scared me.
Being a homebody with health issues, not going out in summer heat is something I enjoy.
It was the perfect time to embark on a project that was on top of mind for a while — Improving my design and front-end skills by applying accessibility as much as possible.
My main goals were:
1. A one-stop guide for all the messy a11y bookmarks and tools I regularly use
2. To build upon my knowledge on accessible design and solve these problems through code
3. To be able to share and get feedback from others
Why accessibility?
At a recent UXR Conference, I had the pleasure of attending a Q&A with Sam Proulx, Community Manager at Fable Tech Labs.
At one point, he said:
Designing for the average is problematic. They do not exist; everyone is an outlier in some way.
On hearing that, a light bulb switched on in my mind.
For the longest time, I knew that it was important for my work to reach as many people as possible, but I couldn’t express why as easily.
I had already started on this project, and hearing someone with expertise solidified the importance of accessibility in design.
In other words, if something is designed for as many people to be able to use it, then it will have the biggest reach. By actively including as many users as possible with ease of access, situations commonly known as edge cases will be reduced right from the start.
I’ll be honest, it is a harder road to focus on inclusive design over ‘ship-now’ design. As many UX/UI designers can attest to, not every stakeholder or team mate will agree with its importance.
On a personal level, I’ve got into hot soup before pushing for more inclusivity.
Common push backs were:
- Additional testing / review would add to scope creep.
- Why waste the time when the data shows only a minority of users have this need.
- Despite my disability, I’m used to less-accessible interfaces and have workarounds.
These are valid arguments I’ve heard from both sides. Inclusive design takes more research, patience and understanding. The results are not always immediate, and there’s always room to learn more as both digital and physical landscapes continue to intersect in design. From my experience, I’ve been guilty of pretend empathy to get a project moving forward, instead of taking a step back to really understand user needs.
As I ruminated, I was reminded of my own inability to last 5 minutes in humid hot weather. I then realized how much I actively reduce this struggle on my own. All these years, I wanted to make the playing field level as much as possible for myself.
Ultimately, it’s a matter of principle to be truthful to myself as a designer. All the user-facing work I do should be as accessible as possible, and by being so, builds trust between me and my users.
With all this in mind, I turned to Notion to start on this resource. By being free, collaborative and available on desktop and mobile, it was easy to start adding content.
Moving on, Goal #2 made up the bulk of my research and skills. I didn’t want the resource to be static. Design in all its forms is ever-evolving; so should my knowledge.
I took this opportunity to practice my front-end skills. Using Codepen, I started by coding out common web-design elements such as buttons to adhere by W3’s WAI/ARIA principles. It became a lot more challenging than I expected!
My process revolved around:
First, reading up W3 practices step by step based on each element.
Next, splitting up elements based on complexity. For example, buttons have fewer accessible requirements over images.
When I got confused, I searched for additional resources, such as those from Mozilla, Deque and CSS Tricks to help me figure out trickier code structures.
Finally, I reminded myself to take frequent breaks and coming back the following day to clean up / edit my caffeinated attempts.
While focusing on this section, I began to notice that I was approaching my code differently. I paid a lot more attention to the details before starting.
Taking the simplest example of buttons, I first considered how many I should represent in an example. I decided on 3 — The first was a native <button>, and the other two were <div> based. The second was a text button, and the third one had a Font Awesome icon.
Then, the number of states. At the most basic level — Active, Inactive, Hover.
Additionally, the :focus attribute needed to be customized because I also wanted to include div buttons.
After that, I factored in a Font Awesome SVG icon as they are commonly used.
Delving into my SASS code, I regularly made attempts to actively use reusable variables for common properties such as margin and padding. In the code itself, I made it a habit to order these properties first to improve readability and consistency.
I stuck to EM units, with a few PX exceptions for border attributes and specific widths that I did not want affected by the elements around it.
To increase readability for both visitors and myself, I turned to Pug pre-processor over HTML. This removed the extraneous <> tags and improved my knowledge of semantic indentation.
All these small considerations made the scale of this project larger than I imagined. However, I’ve enjoyed learning so much about accessibility, and look forward to broadening my knowledge.
After this, I plan to tackle components like menus and tables. In addition, I want to challenge myself further with CSS / JS animations.
On to Goal #3! This is where readers like you come in.
This project is ongoing, and likely will be for quite a while. If you’d like to use it or have feedback, check it out here.
Thanks for reading!
