Last week I got to chat with Evolving Web’s UI engineer, Firat Ikiler. Firat has extensive experience in web design and frontend development, and he’s now one of our foremost experts on accessible design. We talked about how he acquired his accessibility skills, how accessibility plays into his day-to-day work, and some of the critical concepts (and common misconceptions) involved in accessible digital design.
“I learned about accessibility when I started with Evolving Web,” Firat told me. It wasn’t at all something that was on his radar only a few years ago, but now it’s in the mainstream.
According to him, training, whether self-guided or via a structured program, is the best way to learn about accessibility. It isn’t something you’re likely to have learned much about in school, so you’ll need to seek out the right resources to get a good understanding of the fundamentals.
📰 Read next: How we plan a UX workshop, with UX lead Annika Oeser
This is essential, he says, because whenever accessibility is part of a project, “it’s impossible to fix everything all at once”. Any tool you use for auditing will undoubtedly uncover a host of issues—sometimes hundreds, even thousands—which can easily overwhelm someone who doesn’t have a firm enough grasp on accessibility fundamentals.
“When I use a tool such as SiteImprove, I often find myself looking up the different issues that are flagged in order to make sure that they’re relevant and actually need fixing.” You learn a lot as you go along, researching things as they arise, according to Firat; especially since best practices tend to be in constant evolution.
All in all, while formal accessibility training will definitely give you a solid head start, there’s no better learning experience than “experiencing an issue and solving it yourself.” “This is a huge part of the learning process for accessibility, in my opinion,” Firat says.
When I asked him if accessibility was something we needed to tell clients about or rather something they’d request, he told me that in the past two or three years it’s become a requirement in almost every request for proposal we’ve answered. This is likely due to a number of factors, such as the growing body of accessibility legislation and standards and a general increase in awareness towards the importance of digital accessibility.
“One or two years ago it wasn’t really an obligatory thing, but now companies are required by law to comply with accessibility requirements, so they’re definitely aware and asking for it.”
I asked Firat how accessibility played into his day-to-day work as a front-end developer and UI engineer. “I try to apply accessibility rules while the project is in an ongoing state,” he told me. “Trying to fix all accessibility issues at the end of a project would be too much work”
“Every day I’m checking all of the components I develop, making sure they follow accessibility best practices,” he continued. “I try to correct issues as they arise”.
My next questions were about the popular wisdom surrounding accessibility. One of the most common misconceptions in accessible design, in Firat’s experience, is that you always need to provide an alt text when displaying an image.
“If an image is for decorative purposes only,” he explains, “not only does alt text provide no useful context or information, but since it will be read by screen readers, it can make things even more confusing.” (It should have an alt text attribute, however; just make sure it’s set to “empty”.)
This type of misunderstanding comes back to what we’d discussed earlier about needing a good understanding of fundamentals. It’s easy to fall into the trap of blindly applying rules from a list of best practices; knowing how to prioritize and evaluate accessibility issues and solutions is a key skill for today’s web designers and developers.
When designing for a CMS, Firat says, it’s always good to “think about the components as Lego bricks and work to make them accessible wherever a user might place them”. One challenge this introduces involves heading hierarchies: headings go in order —H1, H2, etc.—and the components’ heading structure needs to be constructed as not to break this order when switching their placement on the markup. “That’s the hard part of designing with a11y rules.”
Beyond these intricacies, “design,” he says, “is the more obvious part” when it comes to creating accessible experiences.
He went on to explain that when most people hear the word accessibility, their mind goes straight to things like alt text and colour contrast. Those things are, of course, essential, but they represent the tip of the accessibility iceberg, according to Firat.
So what’s beneath the surface? One word: markup. “The big part happens when you start to develop the page.”
“The big part happens when you start to develop the page.”
“We need to put ourselves in the position of people who actually need to navigate the page with assistive technology,” says Firat, “and develop in ways that retain the full meaning for them.” Even if your site has perfect contrast and every image has an alt text, poor markup can make your content difficult to understand for a large audience.
“We need to put ourselves in the position of people who actually need to navigate the page with assistive technology,” says Firat, “and develop in ways that retain the full meaning for them.”
One important thing to consider is semantic HTML. It's essential in ensuring that the layout of the page’s information makes sense regardless of how it’s displayed via CSS. “Semantics refers to the meaning of the code”
Ensuring that a site’s underlying HTML is written in a way that’s easy to understand for assistive technology like screen readers or mouse alternatives is another critical consideration.
A lot of the flagged issues you’ll come across in an accessibility audit involve missing WAI-ARIA labels. If you don’t have an alt text for an image link, for example, you need to have an ARIA label to indicate what’s going on.
Landmarks are another issue. For example, in Drupal, if you create a navigation menu with the nav landmark, it also creates a role attribute (role=navigation). In all cases, two attributes together that provide the same information are unnecessary and can cause confusion.
Aditus has a great visual overview of how the Government of Canada and Yale University websites look with VoiceOver and landmark navigation, if you’d like to see what this looks like in practice.
Master the art and science of accessible digital experiences
Firat’s first foray into the world of accessible design was with Evolving Web’s accessibility training. Fast-forward a few years, and he’s now one of our in-house accessibility experts. If you’d like to embark on a tried-and-true path to mastering accessibility, sign up for our upcoming training.