Skip to content
Select Page

accessibility + mobile

Updated 23 August — Nope, up until last week this designer and self-professed accessibility advocate’s website did not meet baseline a11y needs. It was also a pain to use on a phone. What got me to care? My site traffic spiked after a social media share. Seeing +300 views in a single afternoon, I finally paid attention.

I had my LLM friend Claude audit every page through its Chrome integration, and it found 18 issues. Below I share what was broken, what’s been fixed, what I have yet to do, things I’ve chosen not to do, and some thoughts on why it was so borked in the first place. Apart from just not paying attention, under the (big, ableist) assumption “How many sight-impaired users are seriously involved in design hiring?!”

TL;DR on where things stand at the time of this writing: 11 of 15 pages have no outstanding structural issues. Alt text is still incomplete on 8 of them. Contrast has been measured, with two deliberate exceptions noted below. Screen reader testing is still to come. Yep, it is my goal to make this site Web Content Accessibility Guidelines (WCAG) 2.2 AA conformant, with a few small exceptions; all noted below with red “x” icons.

Accessibility conformance

These are items identified in Claude’s audit as preventing disabled users from consuming my site content. Items shown with a green check icon have been fixed. Items shown with a gray clock have fixes in-progress. Items shown with a red “x” have yet to be fixed, or will not be fixed. Yes, I am really displeased with icon options for “in progress,” but it’s Summertime and I have jam to can (and a11y fixes to make!).

  • Pinch-zoom disabled site-wide, by WP theme.
  • Focus rings were either suppressed or inconsistent.
  • 3 colors were not to AA contrast minimum. They were close, but not compliant. I chose to keep 2 optional pieces of content non-compliant.
  • Accordions were invisible as actionable objects to screen-readers and folks navigating with a keyboard.
  • Skip link & main landmark absent on all pages. No keyboard fast-path past the navigation to the content. I honestly never knew about either standard!
  • Semantic headers borked.
    • Multiple pages lacked H1s entirely.
    • Others used H2s and H3s for styling, or had no internal header-classed text at all.
    • WP theme used H5s to style image captions.
    • Why do these matter? DOM = keyboard nav. Also, they’re how screen readers parse page content. DOM in design = ohboy I have thoughts!
  • ALT text broken and/or absent.
    • ALT text from the WordPress Media library was suppressed by the site theme.
    • 146 images had no ALT text present in the WordPress library. This is the biggest lift, and is being addressed incrementally.
  • Archived HTML site that is linked-to for work pre-dating 2011, is so incredibly non-conformant and will remain as such.
  • 23 click-targets smaller than 24x24px.
    • I may not address this, tbh—because they’re 22px high, and none are fewer than 24px wide. Fixing may break other things.

What already worked

Every page declared its language. Nothing trapped keyboard focus. No form field was unlabeled (granted, none are used in the site). Links in body were (usually) underlined, not signaled by color alone. The base font size is untouched, so browser text settings were applied to end users.

What were underlying factors?

First off: I’m not a developer. Accessibility needs engineers who care about it, and a11y concepts in code are unusually persnickety. If the code isn’t right, a designer’s intent never reaches end users. Some of it was my own fault, though: header tags used for styling, alt text ignored. Careless, or I didn’t know better at the time.

I chose WordPress in 2012 because hand-coding had become unsustainable. But building on a platform coded by other people, then adding a theme and a pile of plug-ins coded by entirely different teams, meant hundreds of people I’d never met got a bigger say in how I included or excluded disabled users than I did.

I’d also assumed for years that optimizing for vision-impaired visitors to a designer’s portfolio website was akin to helping blind people drive. What I eventually understood: never knowingly meeting a disabled person in hiring didn’t mean none existed. It meant that any who did were invisible to me. Visually impaired design manager? Probably not. Someone with a disability who wants to get to know me before we work together? Possibly. Not many. At the same time, that’s where prioritizing inclusion over exclusion is a choice—and it’s one that matters.

What can other designers do to get ahead of the game? Few of us own screen readers, but we can all navigate websites without a mouse or trackpad. An a11y consultant suggested my team do that for a whole day, and the insight was incredible. Beyond it being ableist to get this wrong, most government agencies and many corporations require A or AA conformance from vendors.

What I’m doing about it

Many items were addressed and resolved within a few days of the audit. Headers as styling vs semantic ordering are the gift that just keeps on giving, from simply not knowing better—and, an epic whack-a-mole of an undertaking to fix. Apparently many theme and plug-in developers didn’t know this one, either, so this will just take a while to fully eliminate. In progress; high-visibility stuff has been done, and the rest will be done as I’m able to finish. The alt text is the long job, because writing 146 useful image descriptions is slow work and bad alt text is worse than none.

The tracker will mark what’s been done, and what hasn’t been done. As with other fixes: the most frequently visited items get priority. The masonry images at the bottom of my About page are my lowest priority. This page will also be updated as noteworthy/major items land. The pink-on-white text almost meets AA, but it doesn’t quite—and because the AA compliant variant is notably-enough different from my brand pink, I’m going to be that-designer and keep it as-is. 

If something here got in your way

Please tell me. I’ve only had my robot friend, Claude, telling me what’s wrong—and I’d value human input from the a11y community! Claude also entirely missed the accordions not being keyboard navigable, in the initial audit—and while Claude also composed multiple new text snippets to fix other things, per my note above a human engineer with a11y expertise needs to have the final say. Sorry, this is one of the many things AI can never fully take over.

My email is below. Describe what happened and what you were using, and I’ll do my best to fix it and write back. If you’d rather not explain the details, “I was blocked on the Projects page” is plenty.

I’d rather hear it than not. ninavizz at gmail dot com

Responsivity

This was a far lower priority to me, than Accessibility. At the same time, it still matters.

  • Homepage animations now work on mobile.
  • Responsive grid-stacking on homepage + projects page now preserves image & header sizes and behaves with more predictability.
  • Frequently visited case study (project) pages: image galleries that correctly stacked/resized.
  • Less frequently visited case study (project) pages: image galleries still need to be updated to ones that correctly stack/size.
  • Icons break and letters are shown in place of icons, on mobile.
    • Problem isolated to one browser, Firefox Focus. Safari on iOS works fine.
    • The problem was determined to be the fault of a JS limiting security feature native to the browser. So, it does it with lots of other websites, too. If I were a big company, that’d matter—but hey, I’m not! Again: good thing I paid attention to learn about this stuff on a prior project, because otherwise, “why this specific browser?!” would have driven me batty.

My website’s audience is design recruiters, hiring managers, and potential colleagues evaluating my work. Mobile has never been a priority here, because those folks do their “real” evaluating on desktop.

The thing I realized when I finally thought about it (cough, last week): when I’m on the hiring side of interviews, I view applicant portfolios on my phone all the time. I also read LinkedIn on my phone more than I’d like to admit. And sure enough—my site got shared on LinkedIn, and every mobile view in that traffic spike came from there.

So, huge priority? No. Does completely ignoring it say something? Yes, absolutely. Basic fixes, then. Not excellence. Just “I paid attention, and I made it not suck.” Honestly, I’d rather spend the energy on something more experimental or evocative, but still usable on both desktop AND mobile. Yes, suckage is a real heuristic: to suck or not to suck. If you actually read this far, I’d love to know—and I raise you an ice cream cone!