Why Accessibility, And Why Now

Sara Soueidan describes herself as an independent web UI and design systems engineer, author, speaker and trainer based in Lebanon. Her client work has included Netflix, Telus and the Royal Schiphol Group at Amsterdam Airport, building digital products with a focus on accessibility, performance and modern front-end tech. She also writes extensively about front-end, SVG and accessibility on her own blog, and is preparing a video course on web accessibility.

Asked where her commitment to accessibility comes from, she traces it to a habit of helping people — an instinct she says she has always had, down to filling out registration paperwork for a stranger at university. When she started her development career in 2013, she spent a few years feeling that her work lacked meaning, turning designs into working code without a larger purpose. She began steering toward clients doing meaningful work, and states that intention explicitly on her Hire Me page.

Her interest in design — never formally studied — grew from the same root. She points to interior design as an analogy: interiors should be designed around how people live. A good interior designer asks the client how they start their day, whether they work from home, whether they entertain, what their hobbies are, and the answers shape the layout of the house. The house is built around the client's life, not the other way around. Accessibility, she argues, works the same way. It is about people specifically; what you build either works for the user or it doesn't, and if it doesn't, it has to change.

Discovering that earlier work of hers may have created access barriers bothered her, and pushed her to learn more. Writing code, she says, makes her a designer: choosing an HTML element, applying CSS that affects semantics, choosing a development strategy such as progressive enhancement, deciding between platform features and a third-party library, and considering how a library performs — all of these shape the user experience.

What a Design Engineer Is

The role Soueidan identifies with most closely is design engineering. In the broadest sense, design engineers specialize in implementing designs. She labels herself more narrowly an inclusive design engineer: someone who uses accessibility and progressive enhancement as the framework for building inclusive interfaces.

Ideally a design engineer works directly with designers, informing their decisions with accessibility and code knowledge, writing HTML, CSS and mostly presentational JavaScript. She stresses that a strong accessibility focus should be part of the job for every design engineer. Beyond that, the strategy and focus differ from person to person — she is a progressive enhancement advocate, others are not. The shared thread is working with designers, helping shape design decisions, and implementing designs so they work for as many users as possible.

Building in Layers

How you break a design into components depends on your process with the designer. Handed a finished page, the work looks different from a true collaboration. Soueidan singles out working with Yan Persy as a favorite: there was no finished design to implement. They worked in tandem, and he changed parts of the design along the way — for instance, moving toward a responsive type scale after they discussed it. Together they built the site as components, assembled components into what they called slices, then assembled slices into the full site.

Technically, she builds in layers, always starting from progressive enhancement: what happens if JavaScript is disabled, and what happens with no styles applied?

  • HTML semantics first. Which elements tell the user what this thing is? If an HTML element already represents the component, use it.
  • ARIA as a last resort, not a first one. ARIA is not an enhancement; it is necessary for many dynamic, interactive components. Ask how much can be achieved with semantic HTML, and how much needs polyfilling.
  • CSS and its effect on semantics. For example, setting list-style: none on an unordered list causes WebKit to drop the list semantics, so VoiceOver no longer announces it. If those semantics matter, they have to be restored, for example with a role attribute.
  • Interactivity last. It is the final layer added to a component.

Native Isn't Automatically Accessible

Soueidan puts today's state of accessibility somewhere between "not too far" and "still far." Awareness has clearly grown, but she notes that her view is shaped by a small circle — she follows fewer than 250 people on Twitter, mostly people who work with or care about accessibility. Plenty of developers simply don't care, and with accessibility you either care or you don't; if you don't, no accessibility work gets done. Others care but get lost in the volume of available resources, unsure where to start — one reason she is building her course. Compared with five years ago, things are better, but she does not think the industry is there yet.

She is skeptical of the assumption that platform-native controls are accessible by default. The dialog element, for example, has carried many accessibility issues for years and only started improving this year. For input type="date", she rarely reaches for it, partly because she has long heard it described as a usability nightmare — technically accessible is not the same as usable.

She quotes her friend Scott O'Hara: technology and user expectations change rapidly, so you should always test that emerging patterns work correctly and that existing patterns keep working as expected. Even something known to work can stop working, since browsers add new heuristics and users change.

On details and summary, she is wary of using them for accordions. When picking any component, the first question is what semantics it conveys, because semantics determine the non-visual interface. summary has a button role, and buttons swallow the semantics of elements inside them. Put a heading inside a summary — which is what an accordion usually wants — and the heading is no longer conveyed as a heading. Some browsers try to compensate for such misuse, but not all of them do, so testing remains essential. If headings aren't exposed, a user cannot navigate by them.

“Technology and user expectations change rapidly. And we should always test to ensure not only emerging patterns work correctly but try untrue patterns continue to work as we expect.” — Scott O'Hara, quoted by Sara Soueidan

Testing: Trees, Tools And Multiple Screen Readers

Her testing routine mixes several instruments, in no particular order:

  • Browser DevTools, to inspect the accessibility tree — the accessibility information the browser builds for assistive technologies, which shows how a screen reader accessing it through the accessibility API will announce an element.
  • Extensions that reveal the document outline or the landmarks on a page.
  • Automated testing tools such as axe DevTools for audits.
  • Screen readers: VoiceOver with Safari on iOS, Narrator on Windows, NVDA with Firefox and Chrome on a Windows virtual machine, and JAWS.

Testing on one screen reader is not enough, any more than testing CSS on one browser is. She admits she was once guilty of the single-screen reader habit. JAWS is not free, she notes, while NVDA is, and JAWS ranks as the most popular screen reader in the WebAIM screen reader user survey. She also mentions Assistiv Labs, which offers browsers for testing with screen readers.

Asked how fast screen readers evolve, she says she has never monitored their release cadence closely. What she does know is that many screen reader users don't update their software as often as developers assume — they are wary of breaking a working setup.

CSS Practice: No Frameworks, A Small Toolkit

Soueidan doesn't use CSS frameworks, though the answer depends on the project: if a team is on Tailwind, she would use Tailwind alongside them — she just hasn't had to yet. She has been, in her words, privileged in her project choices. Her objection to frameworks in general is overhead, and the time spent stripping out unnecessary CSS. Building from scratch is simply faster for her.

Over the years she has assembled her own CSS, moved from project to project and updated continuously — a very small framework with a few utility classes and settings files for type scale and theming tokens. Her preferred combination is BEM, ITCSS and utility classes, adding only the CSS she needs; a utility class is only added if it is actually required, never speculatively. She plans to open-source that toolkit and is considering releasing the course website's framework as well, but both wait until after the course launches.

On the CSS she is most looking forward to, the answer is subgrid, ahead of container queries. She was among those requesting container queries years ago and is glad they exist, but by now intrinsic responsive design with Flexbox and CSS Grid already covers many responsive component needs; she will still use container queries, just less urgently than subgrid. Projects like Prismic Slices in 2019 changed how she builds sites — influencing the Yan Persy work and her own site — by introducing slices as a middle ground between full pages and small components. Having slices inherit the grid of a parent container is exactly what subgrid enables. Cascade layers she wouldn't call a need, but she is excited by how they let her organize CSS the way it is already organized in her head.

The course lives at practical-accessibility.today, which currently just has an overview plus a newsletter signup. Everything is being built from scratch, with a friend hired to build the backend and payments. Once the backend is ready — which she expected by the following month — the site will gain more detail: an introductory video and a fuller table of contents. She hasn't published a table of contents yet because it keeps changing; a section was even inserted between two others a day earlier. A further course update was planned for the next Smashing Hour, aiming for a summer release.

Recording the videos is the part she's least sure about. She hasn't recorded anything final, only some testing and editing, and is approaching the course in reverse order so that recording and editing are easier later. Her main obstacle is perfectionism; she plans to treat recording as if she were on a conference stage, where every word can't be edited. She knows editing is possible, so letting imperfections stand will take self-discipline.

Her final words land on Global Accessibility Awareness Day: learn something new about accessibility, or if you already have the knowledge, fix something on your own site or someone else's — open a PR, close an issue, spread the word, and subscribe to her newsletter.