The Long Arm of Expectations Vs. Deliverables
A cup of hot tea in hand and feeling bright-eyed and bushy-tailed, I set about working with my team on a new project: an already deployed app dedicated to bringing literacy and education to rural villages around the globe. I read the documentation and filled my head with exciting thoughts of bringing my particular brand of accessibility-oriented patterns to the project. I designed wireframes and flowcharts in collaboration with another developer for our initial feature meeting, a dashboard, and together we discussed how best to present to those on the Autism spectrum, or with screen reader tech, power users, someone with epilepsy, and every other scenario two able-bodied women could think of.
Then the first truth-bomb dropped.
We were designing an admin dashboard, not something a child would ever see. I’ll admit I felt a bit crushed in realizing this. Not that an adult should not have the same considerations, but that we had spent several conversations discussing how to present to children. Adults like efficiency. Our designs had to consider how to reduce eye fatigue, rather than building to capture and retain attention. At six months pregnant, I stowed my soon-to-arrive daughter’s fun little toys back into their cubbies, closed all two-hundred tabs related to kid-friendly design, and began research on the metric ton of off-white and gray design blogs meant to cater to working professionals.
Towering expectations thoroughly quashed, we made the necessary revisions and prepared for the first full team meeting. Then things got interesting again.
The Accidental Wins of Developing for Accessibility
When I first introduced the idea of being accessibility-oriented to my team, it was in direct response to a design proposal made before our wireframe mockup: a modal. Armed with YouTube lectures and articles written by other developers discussing some of the more severe cons to modal functionality -- the biggest one being that screen readers can get ‘left behind’ on the original screen while the modal, potentially containing important user flow steps such as a sign up that trigger a token grab, essentially locks the user completely out of moving forward in the app -- I made my case in our first meeting.
There was some hemming and hawing because part of the work had been completed for a modal already, but nobody wants to engineer a bad app experience. I presented my findings, doubled up with an alternative solution that was both easy to implement and would look just as interesting as a sleekly animated modal, and won the team over.
My solution was simple: nest the pre-filled forms we needed to return inside of an accordion. This would keep the original screen clean as was the intended use of the modal, allow a power user to tab all over without interrupting their flow, and -- should the company choose to hire administrative personnel who makes use of screen reader technology in the future -- their admin dashboard is already set up to accommodate.
In my mind, this was the biggest win. By designing this feature with accessibility in mind, which the general public will never see and so who gets to use it is limited, my team and I have contributed to the possibility of future employees who need screen reader tech. We built this feature from the outset for such a user and we delivered on the original deadline, so there is no additional labor cost to retrofit the dashboard later on.
But then, at our first presentation of the dashboard during the stakeholder meeting, we were presented with a shift in plans. The stakeholders were also thinking into the future-- when the returned forms are populated not only with the initially presented basic user data of about 10 fields, but the potential of many subsets of additional attributes per each user. Our returned forms could be hundreds of input fields long at full maturation.
But it didn’t matter. The stakeholder took one glance at our feature and said, “This is perfect.” Had we presented a modal that displayed every user returned from a search in expanded form view, scalability would be a nightmare. A power user would have to tab through hundreds and hundreds of input fields before finding the user they needed to edit data for. Even someone using a mouse would have to scroll for ages. But with the accordions, only the user’s name was presented initially. Once the correct user is found, you’d select that name and it would then expand into the relevant form with appropriate data.
Clean. Scalable. We neatly side-stepped what would have been a full design rewrite had we gone with the original plan. And, most importantly, accessibility-oriented.
A Trifecta of Design & Development Principles
I internalized a great deal of what I learned while working on this project, and while the information wasn’t necessarily ‘new’ my understanding has significantly deepened. Before this project, I approached design with a singularly driven mind: accessibility before all else. All my passion and interest in development was poured into that mold. But as I discovered, accessibility does not necessarily only mean bridging the gap for users who have disabilities or the elderly. They are a significantly important piece of the puzzle, for sure, but a puzzle typically has many pieces.
One such learning moment was during one of our earliest stakeholder meetings, where I eagerly presented my ideas on a potential stretch goal: a flag that would indicate when a particular user needed someone to sign to them.
The stakeholder suggested we set that aside for the time being and focus on the dashboard as it was. The reason? Nothing at all to do with cost or labor hours, but rather a reminder that not every region in the world has a developed sign language to communicate with, even if they do not every child is educated in that language, and some of the regions this app targeted fell squarely in that paradigm.
I came away from that meeting feeling ashamed. Not because of the stakeholder, but because I had inadvertently done the able-bodied thing where I offered a solution to a problem that I’d only superficially considered. The opportunity to grow had presented itself, and I took the chance to rise to the occasion rather than flounder in embarrassment. Going forward, I rearranged my thought process to consider the regions of the world we were developing for instead of the type of person I wanted to reach out to. What were some potential problems that I could solve before we encountered them -- not just for someone who is hearing impaired but for everybody in that region?
Armed with this question, I went back over our codebase and found a glaring flaw. Not in the UI or UX, but in the code itself. The API call we had gone with sent a request for everything available the first time the user landed on the dashboard. There was a search feature to tailor subsequent calls, but the initial idea had been to populate the dashboard and let the admin get to work without a search if they so desired.
In suburban America, the idea of data usage has been almost trivialized. But in rural Africa? There’s no real need to guess as rural America still struggles with limited data usage. We have clear-cut examples of why this is a flawed approach here at home. What sort of environment were we creating for an administrative personnel at their desk in rural India, where it would be all too easy to imagine this person sighing in frustration as they once again hit the bandwidth limit and weren’t sure why because all they are doing is updating some user profile information in simple text form.
Feeling like a fish out of water, I went into the next meeting with a new solution to a problem I thought I spotted in the code base rather than in the UI. I suggested the dashboard simply be inaccessible until the search feature had been utilized. We would make a specific and much smaller API call, only the data the admin needed would be returned, and conserve our user’s data usage as much as possible. The user would then land on the dashboard to begin their work. This was a simple solution that was immediately approved by the stakeholder. I came away from that meeting feeling as if I had truly learned something.
Developing the web should not be a game of selectively catching whichever fish happens to like the bait you’ve set on your fishing pole. Set one post down on the far bank, the other post on the near bank, and string a net between them. You have created a vastly superior collection method to the fishing pole. The wider your posts, the bigger your yield. This is true of scalability, true of performance measures, and true of accessibility. All three are required to make a truly comprehensive and pleasant user experience, and the overlap on the Venn diagram of where these three principles meet is much wider than I’d previously considered possible.
I may have started this project with dreams of making a fun and kid-friendly feature that sticks to every WCAG guideline in existence, but the way that developing for accessibility, scalability, and performance in unison opens the doors to a better experience for all users couldn’t be more clear after this experience. I know my future projects will be that much stronger for it.
Top comments (0)