What is wishcessibility?

As I see it, wishcessibility isn’t a single specific bad practice, it’s anything that inadvertently hurts accessibility when you’re trying to improve it.

Wishcessibility is when the unpaid, open-source maintainer follows the ARIA Authoring Practices Guide without testing the patterns, thinking that they represent best accessibility practices.

Wishcessibility is when the junior developer learns about keyboard-only users for the first time and adds tabindex=“0” to every heading and text node on the page, without anyone in the organization preventing this work from being pushed to production.

Wishcessibility is trusting the accessibility advice of an LLM without checking to see if that is how it works in real life.

Full LLM Output

Me: How does aria-controls help accessibility?

LLM: The aria-controls attribute is part of the WAI-ARIA (Accessible Rich Internet Applications) specification, and it plays an important role in accessibility by helping assistive technologies understand relationships between elements.

How aria-controls Helps Accessibility

• Defines relationships: It tells assistive technologies (like screen readers) which element(s) are controlled by a given control (e.g., a button, tab, or combobox).
• Improves navigation: Screen readers can announce that activating a control will affect another part of the page, helping users anticipate changes.
• Supports dynamic content: In modern web apps, content often updates without page reloads. aria-controls makes these updates more transparent to users relying on assistive tech.
• Enhances context: Users understand not just what a control does, but where its effect will be applied.

Wishcessibility might even be when someone installs that accessibility overlay, because they’ve seen it on a dozen other similar sites and they’ve fallen for the flood of marketing lies.

The common thread here is that wishcessibility, like wishcycling, is always performed by people who want to do the right thing. When a giant corporation decides to whittle their accessibility team down to a single individual with the job title of ‘Resident Sisyphus’, that’s not wishcessibility, that’s just regular ol’ corporate greed. The corporation may or may not be aware that this results in ableism, but the result is the same.

While I would normally be somewhat wary of placing too much emphasis on intent over impact, I genuinely believe it is a useful distinction here because it mirrors the career trajectory of many accessibility practitioners I know. Most of them (including me) started with a sincere desire to make things accessible, and some of us were lucky enough to be allowed to fail, over and over again, until the net good of our work became greater than our failures. Having good intent doesn’t cancel out a negative impact, but I believe cultivating that good intent will result in greater accessibility, turning wishcessibility into actual accessibility.

But as common as that narrative is in my circles, people transcending wishcessibility is quite rare, as inaccessible code and design dominates our industry. It turns out that combatting it is a lot harder than defining it.

How do we combat wishcessibility?

Much of the day to day (and money) in the accessibility industry is driven by a compliance mindset, and this is the inevitable result of the law driving most corporate accessibility efforts. The accessibility practitioners’ standard refrain of ‘it depends’ is not generally acceptable in court, and ultimately, I understand the reasoning behind having measurable, standardized goals, even if it often devolves into box-ticking exercises.

“When a measure becomes a target, it ceases to be a good measure.”

However, as Sherri Byrne-Haber notes in her excellent recent piece ‘Don’t Fall Into the “Accessibility Grade/Score” Trap’, an inherent part of creating standards involves flattening nuance into something reproducible in different contexts. This leads to a proliferation of one-size-fits-all guidance and advice, usually in the form of marketing pieces for different service providers.

Well-meaning developers who want to do the right thing but lack expertise lap up surface-level accessibility content, and the cycle of inaccessibility continues, unfettered by nuance. Without expertise and experience in the practice of accessibility, developers just try to do the best they can with what they’re given. Without organizational support, they don’t have the opportunity to deepen their knowledge, and they can only do so much before the pressures to ship faster inevitably cause harm. I know this, because I’ve been there.

The reason why it’s so hard to get organizational support for accessibility is that the fundamental core of the field is dealing with the inherent messiness of human beings. It’s a rite of passage in the field to receive user feedback that completely conflicts with standard accessibility practice. Disabled people are humans, and being human means having some unexplainable quirks, like the person I once met who only uses cursive fonts on their phone. Though receiving this kind of feedback doesn’t make for straightforward, actionable product feedback, much of how we practice accessibility today is born of people figuring out how to do accessibility for themselves, regardless of what standards say. We can’t forget that the standards are derived from people’s lived experiences, and not the other way around.

One sad reality of our current tech hype cycle means that if you asked your boss for $200 to do some testing with disabled users, they would probably say no, but if you asked them for the same $200 to have access to an LLM so you could generate some user personas, they would probably say yes. There’s something safe and comforting about the answer-shaped results of an LLM, real human experiences distilled down to generalizable averages.

But this is all a farce, a wish, if you will. It’s a lie we tell ourselves to hide the fact that perfect accessibility is actually impossible. The only way to get anywhere close is through systemic support and buy-in so that people can do the gritty, in-the-trenches work of grappling with our shared humanity.

Much like the person at the party tries to impress their friends by attempting to recycle, we aim for perfect tooling scores, closed issues and well-written reports. The other stuff, the actual user experience is relegated to afterthought. I’m not saying we should throw out the baby with the bathwater and get rid of standards like WCAG. They represent an important baseline (and an achievement!), a necessary starting point before the even harder work begins.

Though I, a perpetual optimist, continue to diligently sort out my waste from my recyclables, I know it’s but a drop in the ocean of what we have to do to fix the harm done to our environment. Similarly, I have no illusions about what this blog post can achieve — I know publishing this won’t suddenly make organizations dedicate what it needs to achieve an accessible internet. I just hope that by publishing this, it gives us some language to talk about why the work of accessibility needs us to think beyond the pixels, the code, the standards and the law, about the actual humans we are solving problems for.

(Thank you Jan Maarten for giving me feedback on this piece!)

Web development

Personal & Creative

Cats

I adopted a third cat! I picked her up on a complete whim due to her striking resemblance to my previous cat, and I’m happy to say that I don’t regret it at all. Miette (named by the folks on Mastodon) is settling in well and has somehow managed to improve the relationship between the resident cats, while discovering new ways to be an adorable menace. I want to produce some silly art to help people differentiate my three (kinda) black cats, stay tuned!

Art

Despite the lack of new material on my Instagram, I did draw pretty regularly! I went to life drawing quite a bit, and it turns out that being forced to censor an errant nipple is enough of a blocker to not post the image at all. I didn’t paint much, often choosing quicker medium like markers and colored pencils, which made for a fun combination. I’m not too upset at this development, but I do have quite a few images bouncing around in my head that I want to realize in some way or another. I’m struggling a lot more with getting larger creative projects done. At some point in the process, I start to doubt my own ability to realize the vision and so I end up not trying at all. I think that’s why I’ve been gravitating towards art practices like plein-air and life drawing. You show up and try, and that removes the problem of translating the vision you’ve built up in your head into reality.

One of my few goals for 2025 was to get my work into some kind of art show. That didn’t happen this year! My regular life drawing place might have a group exhibition next year, so maybe 2026 is the year?

Closing thoughts

Wow, that’s quite a bit more than I intended to write! 2025 felt like a whirlwind as I was living it, and looking back, that’s definitely reflected in the amount of stuff I did. I’ve never been one for future goal setting (I hate disappointing my future self), but I do think I can scribble down a few brief hopes and dreams for the next year. Hoping for better things feels like a trap at this point, so I will close this post with a set of general tiny wishes.

What the fuck is a ‘fuck off contact page?’

A “fuck off contact page” is what a company throws together when they actually don’t want anyone to contact them at all. They are usually found on the websites of million or billion dollar companies, likely Software-as-a-service (SaaS) companies that are trying to reduce the amount of money they spend on support by carefully hiding the real support channels behind login walls. These companies tend to offer multiple tiers of support, with enterprise customers having a customer success manager who they can call on this ancient device we call phones, whereas the lower-paying customers may have to wrangle various in-app ticket mechanisms. If you solve your own problem by reading the knowledge base, then this is a win for the company. They don’t want to hear from you, they want you to fuck off.

In other words, this is entirely inappropriate for the kind of service-based agency that our client was. The billion dollar SaaS company wants to reduce the number of incoming inquiries, and is hoping to weed out anyone who is not determined to contact them by giving them unsatisfying options. The service company wants to show how helpful they are and cultivate leads. These are fundamentally opposing goals.

Let me explain further. I’m not sure about you, but as a user, when I see a button that says ‘talk to our sales team’, I treat the entire region of the page with the same trepidation as nuclear waste. The page is now a no-go zone, and I try to exit as quickly as possible, knowing that whatever my original query was, I’m going to have to solve it unassisted. Seeing as this is a company who makes money off of convincing people to let them handle the easy stuff, adding friction to this key part of their sales funnel just doesn’t feel like a winning strategy.

How the fuck did you convince them to change their minds?

Try as we might, we couldn’t. In all honesty, we probably could have done more in order to talk them out of it, but the project had gone in such a way where we were focused on trying to talk the client out of changing other things that would drastically increase design or development time beyond the initial scope. In other words, we were too busy putting out other fires. This re-designed contact page, as certain as we were of how bad of an idea it was, wasn’t a fire, so we let it through.

The project finished on time, everyone got paid, and the client was happy with the end result, but I still felt very disappointed in the whole thing. While I personally believe in the value of good design, I also believe there are a lot of smoke-and-mirrors in the industry, and I hated the thought that I might have inadvertently contributed to it. Even if the client is happy, it didn’t meet my internal bar for a quality product worth sticking my name on, and I feel like I’ve let down both the client and the end-users.

How the fuck do I avoid being in a position where I’m asked to implement a ‘fuck off contact page’?

I think our problems started from before we even began to touch a single design tool. As a favor to one of the folks involved, we had discounted our rates for this client, and I think that set us off on the wrong foot. Instead of seeing us as people who brought valuable knowledge and expertise to the project, they saw us as the hands that would execute their vision.

Especially for those not familiar with the process of design, it can be tempting to see things like discovery and wireframing as obstacles to be cleared before you get to the fun part, designing the visual identity. Unfortunately, many designers are also guilty of this!

As service providers, I believe we need to do a better job on educating clients on the design process and why each step is so important. This is radical idea in some circles, but knowing why you’re building something is a necessary part of doing a good job at it! That’s why we do things like determining the architecture before we start thinking about the brand. Flow charts and diagrams are not as fun as interactive prototypes, but they’re much more important to get right.

Also, the discounted pricing probably didn’t help — instead of signaling that we were doing a favor out of respect for them, it just signaled that we were easily exploitable. There was a lack of trust throughout the process, on both sides. While I really want to believe that I can have the kind of relationships with clients where constructive disagreement is welcomed and valued, how I get there is still something I’m figuring out, even many years later.

I think that’s part of the reason why I blog. By blogging, I’m putting a body of work out there that communicates my values and ethos. While much of the details of my client work has to remain private, these posts can be public, and hopefully they can help me find people who resonate with what I have to offer. Or you know, just be bold enough to communicate ‘Fuck off’ to those who don’t!

(Feel free to reach out if you’re interested in working with folks who care, maybe a little too much, about doing right by your users.)

Links and Resources

I hit publish on this as I listened to Andy Bell’s recent talk at Beyond Tellerand. It has SO many gems of wisdom about the core skills required to deliver successful client projects. It’s also why I love working with Set.Studio, check ‘em out.

Web Development

Tech Industry

Miscellaneous

What newsletters are you reading?

Tell me what you’re reading! I always feel bad about tagging people but if you make a post, I’ll link to it here!

Why implement grid-awareness?

Many folks may notice that the in brief approach outlined above, there’s a non-trivial amount of code required to implement grid-awareness. Since less code = better performance = greener websites, isn’t this a bit counterintuitive, if not self-defeating? I hear you, and it’s something we’ve thought about a lot as a group, and the Green Web Foundation have addressed this question excellently in their FAQ. Essentially, this is an experimental approach to see if this is a viable way to reduce the carbon emissions of websites.

I would love nothing more than for every site and application to be the best version that it could possible be, but we’re definitely not living in that world at the moment. The collective push by performance, sustainability and accessibility advocates have not been able to make the industry shift meaningfully, despite strong real world incentives to make sites more usable for more people.

When every company is asking ‘How can we do more?’, I think it is a powerful mindset shift to think ‘How can we do more with less?’ This question is typically framed in terms of having less budget or monetary resources, but when asked in terms of a performance budget or a user interface design, it forces you to think about what parts of the user experience is really necessary.

A big part of the Green Web Foundation’s philosophy with this project is raising awareness about the inherent connection between digital and physical worlds. To a designer using the latest MacBook with a Gigabit internet connection, performance concerns may often feel completely abstract and divorced from reality. Tools that remind us that yes, the choices we make do have an actual impact, can be an important part of driving change.

We can’t ignore the impact that digital systems have on our environment, especially at this critical moment when electricity usage is greater than ever. Sure, the energy saved from efforts like this may be a drop in the bucket compared to what AI is using, but I don’t think we’ve ever solved any societal problems by not trying to think about or address them.

Though my preferred approach is to build progressively enhanced, lean sites in order to make them sustainable, many brands prefer to express a commitment to sustainability in more overt ways. The visibility and positioning of something like a grid-aware toggle can be a powerful motivator for certain types of companies.

For example, I once had a client that sold sustainably made household items, and they wanted their website to reflect their commitment to sustainability. I suggested the usual high-impact things like reducing the size of media and using a static site generator. They didn’t mind the statically-generated approach as it helped them save on hosting costs, but they didn’t want to give up their use of background video, a decision that forced every user to download an additional 6MB of video. Instead, they suggested implementing a dark mode toggle, which I was more than happy to do to improve accessibility, but deep down, I knew that this was still a a net loss. If grid-aware websites had existed back then, maybe we could have reached some kind middle ground.

Ultimately, the end goal of the grid-aware websites project is to not build a single library, but to embed this kind of thinking into the greater web ecosystem. Much like how we have media queries for things like preferring reduced motion or using forced colors mode, what if we could have a media query to prefer a simpler, more environmentally friendly experience? The future is uncharted territory, and this is an open invitation to invite the web dreamers, gardeners, and explorers to join in.

The breakdown

Step 2: Determine how you’re going to make it happen

Following the tutorial provided by the Green Web Foundation, I deployed the site to Cloudflare, then installed the specific grid-aware worker they made (there’s also plans to build out a Netlify equivalent). Out of the box, the plugin provides a drop-in connection to the Electricity Maps API once you plug in your key, which is very helpful. This worker will get the request, get the user’s rough location, and then determine the current state of the grid.

It can also optionally inject the grid-aware status bar web component, which will show some data about the user’s current grid and allow the user to manually toggle between the modes. The status bar is optional, you can also build your own custom solution to give the user control over their grid-aware experience.

The website design changes in response to the grid are unique to each website, so this is an implementation step for us. On the Cloudflare version of this worker, this involves using the HTMLRewriter API to transform the markup before it’s sent to the user. Even though the underlying approach would be the same for both 11ty and Astro, due to the different bundling strategies, we have to implement them slightly differently. Let’s take a closer look.

11ty

Ah, 11ty, my old friend. I haven’t picked it up in a while, but I’m excited to play around with the new WebC stuff, which lets you write single file components. The WebC architecture in 11ty is a really interesting idea, and the same technique that can be used for setting up critical CSS and JS can be used to set up grid-awareness.

One thing I particularly like about 11ty + WebC is that it lets you put scripts and other assets into designated buckets, while still allowing the author to write them in the main component file. I’ve included an example below.

<!--This goes in your component file -->
<script webc:bucket="bucketName">
	/* Your script stuff goes here! */
</script>

<!--This goes in your layout or page file -->
<script @raw="getBundle('js', 'bucketName')"></script>

This is really handy! We can now separate the JS that is optional by putting it in it’s own separate bucket, so we can easily stick a data-gaw-remove attribute on it it for our Cloudflare worker to strip out. An approach like this is an excellent authoring experience, as we aren’t limited to putting the data attribute on script tags, we can put it on markup, style tags, etc. Our resulting HTML Rewriter API function is super simple as a result, we just remove all of these elements in one fell swoop.

  new HTMLRewriter().on(.on('[data-gaw-remove]', {
    element: (element) => {
      element.remove();
    },
  });

Astro

Astro has a little more ‘magic’ in it than 11ty, and it made it a little harder to figure out a solid grid-aware approach. Ideally, we could use the same approach as 11ty and just take away anything with the data-gaw-remove attribute on it, but Astro has this thing where if you add any attribute to a script tag, Astro will not process it. It’s typically used as an escape-hatch for things like analytics scripts, so they aren’t included in a bundle, but it poses a problem for us as we still want to process our scripts, we just want to add something extra on top.

To split the code up into different buckets, we’d probably need to hook into the underlying Vite/Rollup configuration. That felt beyond the scope of this small demo, so I came up with a quick-and-dirty solution. I noticed the bundled scripts for each Astro component kept the name of the component in the script src. I decided to use a prefix-based approach, and used the HTMLRewriter to strip out scripts that started with “GA-”. In terms of code, this is almost as simple as the 11ty version, but quite a bit less flexible — I can’t see people relying on opinionated naming as a way to implement this in real life scenarios.

new HTMLRewriter().on("script", {
	element: (element) => {
		if (element.getAttribute("src")?.includes("GA-")) {
			element.remove();
		}
	},
});

Is this another thing I have to care about?

I know what you’re thinking. Grid-awareness might seem like just one more item in the long checklist of things you should probably do, but don’t have the time or budget to do.

Here’s the thing, I think grid-awareness fits really neatly into all those other things you might already be doing to make a better website. If you’ve already got a website that has features to reduce data usage or utilizes progressive enhancement/graceful degradation, you already have the bones for a grid-aware website. Grid-awareness is in it’s infancy, and it isn’t exactly a specific practice in the way progressive enhancement is, it’s more of mindset.

Grid-awareness on an large social media application with video data might look completely different to grid-awareness on the Branch magazine website, and that’s totally fine. For example, the Branch magazine website doesn’t load web fonts and heavily compresses images when the grid is ‘dirty’. That approach is completely different to the one I’ve done here, and that’s okay! One of the main points I want people to take away from this is that you get to decide how to implement this.

It doesn’t have to be a completely new thing, either. Many applications already have something like a data saver mode, or a lower power mode. Grid-awareness could be an extension of these settings, and utilize the same core logic, only switching up the conditions when this logic is triggered.

Challenges

The first major blocker for the grid-aware websites project is the cost of the Electricity Maps API. The Carbon-Aware pricing plan required to make this work is currently 99 Euros a month (a recent development that occurred after the project started), a hefty price to cough up for a smaller organization. It’s hard to justify the expense when the entire architecture required to run the site may be cheaper, or even free. If you feel strongly about this, feel free to weigh in on this Github Issue. If there is a strong demand for a free plan, Electricity Maps may consider implementing it.

This specific proprietary API isn’t the only option. The EU has passed laws requiring member states to make this data available, and it may be possible that there will be greater options for this information with the greater shift to greener energy.

The one thing that might be the biggest blocker for implementing grid-awareness at scale is that it involves all levels of the stack. Unlike areas such as accessibility or performance, where even one lone advocate can make a big difference, the method to implement grid-awareness requires a knowledge of all the moving pieces required to make it happen. The person who knows how to design a multi-layered, grid-aware experience is probably not the same person coding that front-end experience, and they’re probably not the same person with control over the building and deployment of the site.

Smaller projects like this demo where one person is in charge of all aspects can more easily implement grid-awareness because the complexity is significantly reduced, but at the same time, these kinds of sites are already most likely to be the least problematic in terms of carbon emissions. The same kind of paradox occurs with the tooling choice — tools like 11ty and Astro that make it easier to split your JavaScript up are much more likely to produce performant outputs already, making it uncertain if implementing this is worth the tradeoff. Once you pick up a bigger web framework, you’re more likely to benefit from implementing grid-awareness, but the barrier to do so will be much higher.

The grid-aware advisory group is well aware of this adoption barrier and has representatives from open-source CMS communities, who are actively working on grid-awareness libraries for CMSes like Wordpress (Github Link), Drupal, Umbraco and Wagtail on the server-side. If grid-awareness was a solved problem at the deployment and ops layer, then it would be easier for designers and front-end developers to implement without worrying about this logic.

Conclusion

That’s all I have on grid-aware websites for now! It’s been hard to summarize a years worth of tinkering and thinking into a single blog post, and I really hope I’ve done the subject justice. If you are at all interested in getting involved, the ClimateAction.tech Slack is a wonderful group where much of this conversation happens. Or, you can try to implement the code yourself, feel free to reach out if you want to give this a shot on your own site.

Related reading

• Green Web Foundation’s developer tutorial
• Fershad’s case study for implementing grid-awareness on his own site has all the technical background you need behind the plugin
• Fershad also has a writeup of the corresponding visual changes on his site
• Progressive enhancement and graceful degradation in the context of grid-aware websites
• I’ve linked the Branch Magazine case study before, but I’m going to do it again because it’s my blog and I’m the boss around here

The Green Web Foundation rocks

The folks over at the Green Web Foundation are some of the loveliest people I’ve had the opportunity to meet. Chris Adams is so incredibly articulate that even having my words summarized by him after a group discussion feels like a transformative experience. Hannah Smith has such a joyous presence that even though the meetings usually occur after a long day of work in my timezone, I instantly feel perk up whenever I’m in one. Fershad Irani, AKA Fish, is so cool and smart that you think he would be incredibly unapproachable, but he’s actually incredibly friendly and chill. All that’s to say, if you ever get the chance to work with or support the Green Web Foundation, don’t pass up the opportunity! People working at smaller, mission-driven organizations don’t get enough thanks or recognition compared to companies with larger marketing budgets, especially a time when the wider culture is doing its best to trample all over their work. I just wanted to say a big thank you to the Green Web Foundation for all their hard work!s

This leads me to the title of this post, which is to read the latest issue of Branch magazine. This issue is called ‘Attunement – Designing in an Era of Constraints’, and has a lot of wonderful writing about what folks have been up to in the grid-aware advisory group. As I’ve mentioned, I’ve always found it difficult to connect the things I cared about with my work in web development, and if you relate at all to this sentiment, you might find this issue an especially good one to check out.

Favorite articles

• A Digital Almanac: Attuning Our Web Habits to the Natural World by Lucy Sloss. Quiet and contemplative, this piece contextualizes sustainability within larger trends in technology in a way that makes me feel hopeful.
• Designing a Grid-Aware Branch by Hannah Smith, Fershad Irani, and Tom Jarrett. You all know I love a good case study. This one is no exception, I especially love all the little details and specifics, there are a tons of valuable practices here that make me reexamine how I build websites.
• AI, Climate, and the Global Majority: A Just Transition Toward COP30 and the People’s Summit by Lori Regattieri. A thought-provoking look at AI and the energy crisis from the perspective of climate justice and technological sovereignty. If this has to happen, it needs to happen with a consideration for the many folks who would be most affected by climate disaster.
• Finding Harmony between Business and Sustainability with Grid-Aware Computing by Michael J. Oghia, James Hobbs (Contributor) and Andy Eva-Dale (Contributor). As an accessibility person, communicating why you should implement something to corporate stakeholders is something I’m simultaneously pretty familiar with and not very good at. Who would have known that ‘you should give a shit about other people!’ is not a particularly effective argument in the boardroom. I appreciate the deep dive into how to communicate the importance of giving-a-shit into corporate speak.

Author’s note

Hey Nic? You’ve forgot to explain what the heck a Grid-aware website actually is.

I know, and it’s coming! Due to some changes in the availability of the Electricity Maps API, I’ve had to hit pause on a demo, and I’d really like to have something that people can click around. In the mean time, the aforementioned Branch Magazine redesign article has a really good explainer.

A note from the present day

Hi, it’s present-day Nic here. I feel bad that this draft has been sitting in my posts for the better part of a year! I had pretty much drafted the complete text back then, but taking three screenshots proved to be an insurmountable task for an entire 8 months, whoops! But we’re nearly at the end of this journey of building this site, thank you for still reading these and all your kind words!

I also found some time to add drag and drop (desktop only) + better window layering without compromising the no-JS experience. A big thanks to everyone who nudged me to do so, I probably would have never gotten around to it otherwise. That’s one of the beautiful things about a progressive-enhancement driven approach. Coming up with a core, workable experience and adding flourishes later means that the older behavior can still exist as fallback behavior. I initially used CSS to manage layered windows with as little complexity as possible: any window with a focused element in it just had a higher z-index. I’ve now added some JavaScript on top to make the stacking feel more natural, but the old approach still totally works to ensure all content is readable even without JS!

Back to the past…

Fonts

It’s at this point I start doing some performance testing. One of the key issues was that I had a huge amount of Cumulative Layout Shift as the fonts loaded. The font I had chosen, W95FA, is pretty narrow compared to other fonts, and I wanted to see if I could minimize the amount of jank as the fonts came in. The layout of my site meant that containers resizing would feel especially choppy. I also knew that I would want to add a toggle between pixel and anti-aliased fonts, as it was a setting I’ve seen in video games to improve accessibility for those who struggled with reading pixel fonts. Switching between the two would need to feel pretty seamless, with as little layout shift as I could manage.

At some point, I had stumbled upon the website Modern Font Stacks, which provides a list of font fallbacks by style to cover every OS. I really liked the Humanist font stack, but the question remained on how to make sure the transition was seamless.

Luckily, I discovered this helpful little Font Fallback tool, which lets you upload a font and then visually adjust the new size-adjust, ascent-override, descent-override and line-gap-override properties with sliders in order to create a seamless fallback. This is an absolutely wonderful tool, my only gripe is that it doesn’t have a whole bunch of fallback fonts, so I had to edit the source code so I could make it work with my chosen stack. So yes, I acquired every single one of these fallback fonts, modified the source code of this website to allow me to use it as a fallback, and played around with the little sliders until it was just right for each fallback. I think this kind of touch is the kind of thing that adds a lot of polish to a website, but is often overlooked.

Artwork

I’ve always been torn about having an artwork section on my site. It’s not at all related to what I do professionally, and I always wondered if I would be judged for having a section dedicated to it. Through the magic of the indie web, I stumbled Josh Crain, a fellow web developer’s website, and I really enjoyed the artwork section. His work is full of light, and I really resonated with his artistic journey. I’m so glad I found his site, because it helped me decide that I didn’t particularly care any more if anyone thought negatively about it, and I implemented an artwork section for my site! This isn’t a super popular page on the site, but those who like it seem to really love it, so I’ll chalk this up as a success.

Selecting the pieces was the most difficult part. I knew I wouldn’t be able to feature too many works on this page with the layout that I had in mind, so I had to be more choosey than I’d like. In the end, I chose a mix of pieces from the mediums I’ve been enjoying in the past few years (digital, but only the HEAVYPAINT program) and gouache, with a mix of plein air pieces in there.

Development was straightforward as this was one of the very first sections that I designed when coming up with the initial idea for my site. As soon as I saw my first View Transitions demo, I knew I wanted to utilize it to power this section. When a window in this section is maximized, the window itself is cross-faded and the caption fades in, but a separate view transition on the artwork makes it scale up smoothly. I really can’t believe what you can get with CSS (and a sprinkle of JS to manage state and fallbacks!)

Work

I was really dreading the work section. Because I had places where I was showing desktop screenshots, mobile screenshots, sometimes in comparison with each other, I knew I had to come up with layouts that would work for 1-2 images of any aspect ratio and an optional caption, which is a lot more challenging than a designer-lite like me initially thought. I really did not want to be in a position where I would have to write new styles every time I added a case study, so I decided to embrace asymmetry and came up with a limit of three image layouts that I could use as needed. This part of the site seemed like the perfect time to try out container queries, as we only care about sizing within the avaialable window space, not the whole viewport!

I also decided to keep the chunky background line I had in the previous version of my site as a design element, with the addition of pixel half tones in order to fit in better with this version. I’ve always wanted to do fun, CSS Grid overlapping layouts with different textures, but never had the chance to on client work. I try to treat my portfolio like a garden: you don’t need permission to grow things in your own garden, so you might as well plant what makes you happy. I’m not entirely sure if this metaphor is appropriate, I’ve never grown up in a place where I could have a garden and I am well known in my friend group as a plant-murderer, so please do not construe this as actual gardening advice.

It doesn’t work when ‘hidden’

One of the cardinal rules of live regions is that they work best when the element already exists on the page. Another rule is that they don’t work if the part of the accessibility tree they are in is hidden from the accessibility tree, ie. when display: none, the hidden attribute, or any other method of hiding text via CSS is applied. This means they need to be present in the DOM, and the content within them is accessible to screen reader users.

This has a lot of potential to confuse users. For example, let’s take a standard e-commerce announcement, when a user adds an item to cart, you could have a live region announcement that says ‘(item name) has been added to the cart.’ (We’re just not going to get into whether or not this is the best technique to communicate this particular example message, or we’ll never get through the article. I gave a whole talk on this at one point.)

That means, the screen reader user has the potential to accidentally stumble across the message as it is just inserted in the DOM. How confusing would it be to accidentally find a message like this as you’re browsing the page? Wouldn’t you think you’ve just added a second item to your cart?

As a result, accessibility experts typically recommend you 1. stick the live region somewhere where a user is unlikely to encounter it, such as the bottom of a page and 2. wait a period of time, not too short and not too long of a time, before clearing out the live region so that screen reader users don’t accidentally stumble across it again. A mysterious timeout number that no one can really nail down, definitely not a code smell, right?

The fact that live regions work most consistently when the element already exists on the page is in opposition to how developers usually would implement such status updates. If you need live regions, you’re probably working on a somewhat complex application, possibly managed by a JavaScript framework. You probably don’t have all possible status messages already rendered on the page, but hidden to users. You’re likely creating these status message elements on the fly, and adding them to the DOM whenever needed. This means that the way we show status messages to sighted users and the way that live regions work are fundamentally in conflict with each other.

Even if you listen to popular advice to avoid live regions wherever possible, if it does turn out that live regions are the most correct way to implement your desired UI, you may need to set up two different interfaces, one for sighted users and one for non-sighted users. And I think we all know who gets the short end of the stick when the deadline looms and the budget gets cut.

Fun with modal dialogs

Requiring live regions to not be hidden is not the only trap. As I mentioned before, live regions need to be accessible within the current accessibility tree, which means that content that is outside of a dialog or made inert through other means is ignored. In simpler terms, if you need announcements within a modal dialog, you need a new live region within that dialog. Managing this overhead is yet another piece of kindling for the bonfire of how terrible live regions are to work with.

Developers are lazy

If you’re reaching for the live regions, you probably have good intentions. Because there isn’t really a purpose for live regions other than for accessibility, if you are trying to use them it probably means you want to do the right thing. While live regions are not quite up there with aria-activedescendant in terms of ‘how much does implementing this feel like navigating a minefield’, the truth is that every developer who reaches for live regions ends up needing to implement them in a very particular way

It all feels like a lot of unneeded effort. When the underlying primitives are difficult, this has a knock-on effect where everything that depends on that primitive gets more complicated to implement correctly. It always sucks when an interface is not accessible, but when it is not accessible despite everyone involved wanting it to be accessible, that sucks even harder. This leads me to my next point…

The inconsistency is built in the spec

When I was working on Audiom, something happened that clearly highlighted to me why live regions are flawed and never going to solve the problems we need it to solve.

Navigation worked well in NVDA, but JAWS users faced enormous lag when holding down an arrow key (ie. traversing the map very quickly and queuing up many messages). When we filed an issue, a JAWS developer informed us of what it said in the spec:

When regions are specified as assertive, assistive technologies will immediately notify the user, and could potentially clear the speech queue of previous updates.

In case you missed it, the key word here is ‘could’. This means that two different assistive technologies could have completely different behaviors, and it would be fine according to the specification. In our use case, being able to clear out the queue of messages is essential for making it work on all screen readers, and this is something not supported consistently by live regions.

I know some folks are probably thinking, couldn’t you just debounce this? We did try but with an application like this, there wasn’t really an acceptable ‘timeout’ that didn’t make the experience worse for users of other screen readers. If an audio track for a movie or a video game was a couple hundred milliseconds off, it would be quite jarring. There are just some use cases that require more control over timing.

The ARIA Notify explainer mentions an interrupt property that isn’t implemented in this initial spec, but it would be fantastic to implement in the future. It mentions other real-world use cases as well, such as interrupting a stream of chat messages when a user sets their status to ‘Do not disturb.’

People who are involved in specifications know that generally speaking, changing existing things is pretty difficult due to the backward-compatible nature of the web, but creating new, better things is slightly easier, and I really believe that ARIA Notify has the potential to be that better thing.

Potential for improved functionality from assistive technologies

The way screen readers interact with live regions is okay, at best. One of the reasons why accessibility experts often recommend against live regions is that they are really fallible, even when you do everything correctly. In the ARIA Notify explainer, it says that:

The available priority controls (assertive vs. polite) are not well specified and are up to the interpretation of screen readers. In one instance, an author wanted to make a live region announcement immediately following a user action to supplement it with related context. However, the polite setting was too polite; a subsequent focus change would always mute the announcement. The assertive setting was too assertive and caused subsequent (important) focus change context to be lost while the assertive announcement was made.

In my experience, I’ve found this exact scenario to be very common. Users interacting with an application as normal can accidentally skip over the live region announcement just by continuing to use the website, without recourse.

For normal text that is in the DOM, a screen reader has the ability to drill down into the text, playing it again if needed or traversing it letter by letter. Live regions don’t have this, so at Audiom, we added a keyboard shortcut to announce the most recently announced message, and we also built a speech log component if users needed to revisit certain text in more detail.

I haven’t seen any discussion around this, but I think it would be amazing if screen reader vendors could implement similar features into the screen readers themselves. If a user is interrupted for any reason, being able to replay the last few announcements with a shortcut key would really help the usability of complex applications. A potential new API creates an opportunity to really think about user experience enhancements like this without breaking anything.

The internationalization issue

I would be remiss if I didn’t mention a potential flaw I see with the ARIA Notify API, which is essentially the same problem with ‘aria-label’ and translations. Of the techniques to give a control an accessible name, aria-label is usually ranked near the bottom, with a key reason being that it doesn’t play well with automatic translation tools.

In my testing, I found that live regions did translate with things like the in-built Google Translate in Chrome. Even if it was a slightly janky experience where the announcement would be read first in the original language before announcing the translated one, hearing something in the correct language is certainly better than it being ignored.

I’m not a translation tool developer, but from my outside perspective, I do think it would be much easier to watch the DOM for HTML attribute changes (which aria-label would fall under), rather than JavaScript text announcements, so if these tools aren’t catching aria-label, this doesn’t bode well for any ARIA Notify announcements.

I would personally really hate to see something like ARIA Notify be implemented only for it to be advised against due to the lack of translation support, so I hope we can think through this a bit more and avoid creating something that technically exists but is practically useless, such as aria-controls, or something that is useful but strongly recommended against, like aria-label.

Closing thoughts

I hope this article has communicated why I think we need something better than live regions for screen reader announcements. I know things like ARIA Notify are not as cool and fun as potential layout features such as CSS Masonry or View Transitions, but I genuinely believe that having different tools for screen reader announcement would make it easier to create accessible applications.

I don’t see ARIA Notify as replacing live regions, they still have their place. I would still recommend using a live region for text that is visible on the screen that you just need to update, such as updating the visible search results count when new results are fetched. ARIA Notify would just add a little more control where it is desperately needed. We have many ways to hide an element in HTML and CSS, each with different, valid use cases, so why can’t we have multiple ways to announce text to assistive technologies?

(Thank you EJ Mason for pushing me to publish!)

The exam

I signed up for the November 2020 exam around the time I ended a full-time engagement with a long-term client. Although I tried my best to implement accessibility in the day to day work, I really wanted to be able to do more work that was specifically focused on accessibility, and getting certified felt like the best way to get my foot in the door. Of the available credentials, the IAAP WAS certification seemed like the one that aligned most closely with my goals as a web developer who also does accessibility (as opposed to a designer, UX researcher or tester).

When I signed up for the exam, I was still doing full-time work. I made paper flash cards, as I’ve always found the physical act of writing to be essential for actually remembering things. I also signed up for the paid course at Deque University, which I found to be quite helpful (not sponsored). Once I ended the full-time contract, I had a couple of weeks where I only had part-time work, so I basically studied as much as I could for those two weeks outside of my working hours. I was lucky enough to pass the test on the first try, which was great for me because I don’t know if I would have been able to find the time to study on top of a full-time job.

The questions I struggled with the most were questions about keyboard shortcuts for different screen readers, and questions about different laws around the world. This may be a little odd, but when I use the keyboard, I don’t consciously think about what keys I’m pressing, I basically remember what finger motion I do to activate the key. I also have a fancy ergonomic keyboard so I remap a bunch of default shortcuts to be more comfortable for me, so remembering combinations that feel arbitrary is genuinely pretty difficult.

I’m more well-versed in the legal aspects now, especially now that I’ve done more accessibility work, but I do feel that it is slightly western-centric in that I’m sure there are plenty of other accessibility experts who do not live in the regions that the test tends to ask about. Some people have also levied the criticism that such a focus on rote memorization for these kinds of facts is ableist, which I think is important to keep in mind.

The impact it had on my career

I do think it helped, marginally. In my experience, people in the accessibility field do not find IAAP certifications to be a particularly useful as a benchmark for how ‘good’ someone is at accessibility. Almost none of the folks I respect the most in the field have a certification. However, it is somewhat of a useful tool for appealing to the ‘box-checking’ folks who might be in charge of an organization’s accessibility processes. I’ve been on teams where I was the only person with a IAAP certification, and the fact I had one was seen as an asset for those seeking work in government or education, because they could point to my certificate as additional validation.

As a self-taught developer, I’ve often had bouts of imposter syndrome. It can be difficult to feel secure in your accessibility knowledge when you know that mistakes can contribute to the further oppression of marginalized groups. This is something I genuinely struggle with, even while trying to remind myself that I am still human and that I will mess up sometimes. Having some sort of validation in the form of a very expensive piece of paper did feel like a shield against the insecurities in the early part of my career.

However, despite this, I can’t say I’ve ever gotten any accessibility work by virtue of just being listed on their site. They used to have a public facing page that just listed everyone by name, but now they’ve switched to a verification form type of interface. They’ve also now listed my country as China which is not particularly useful for me as I do not speak Mandarin well enough to do accessibility work with it and it may deter my actual audience (basically anyone who speaks English) from looking me up.

If I try to think about all the inbound leads I’ve had related to accessibility, most of them were via word-of-mouth. Of those who didn’t reach out as the result of a direct referral, one mentioned a blog post that I wrote, and two have mentioned watching my recorded talks on accessibility. This definitely isn’t a statistically significant number of results, but going forward I’m likely to invest more time and effort in those areas instead.

The CAEC process

We’ve reached the spicy part of the post! I recently came across this post by Rian Rietveld. For those in the accessibility field, Rian should need no introduction. She is a pillar in the industry and her contributions have made the web a better place. The post is well-worth the read, but to summarize, Rian was frustrated that her paid, public work for various governments and on the Wordpress Accessibility Team did not count for her Continuing Accessibility Education Credit (CAEC) requirements.

What are CAECs? I’m glad you asked! The IAAP certificates are valid for 3 years, and require a certain number of hours of additional engagement in the accessibility field outside of paid work. The exact number of hours varies by certificate, the WAS certificate I took requires 35 CAECs, which is around 12 CAECs a year.

To understand Rian’s post, we need to look a bit more at the specific CAEC requirements. I’ve rounded them up into the summary below:

1. Professional Development CAECs are counted in 15-minute increments rounded up to the nearest number. Accepted formats:
   • Attending live/archived webinars or workshops
   • Attending and completing online course(s)
   • Attending accessibility presentations at industry conference(s)/summit(s)
   • Attending course(s) from educational institutions- Note capped at 15 CAECs per course per year.
2. Sharing Your Accessibility Knowledge CAECs breakdown
   1. One hour of structured teaching content delivery = 3 CAECs (two hours to prepare for one hour of structured delivery)
   2. Featured speaker or speaking engagement = 2 CAECs per hour of speaking
   3. One Year’s Active Volunteer Committee Work within the Accessibility Profession= 5 CAECs per committee
   4. Publication of blog series (more than five) regarding accessibility = 5 CAECs per year
   5. Publication of professional or scholarly article = 5 CAECs per article
   6. Publication of a book regarding accessibility = 6 CAECs
   7. Organizing accessibility Meetups = 1 CAEC per event as the organizer
   8. Organizing local accessibility conferences = 5 CAECs per event. Must be listed as a lead position on the conference organizing committee.
3. IAAP Volunteering CAEC breakdown
   1. One Year’s Active IAAP or G3ict Committee Work = 5 CAECs per committee
   2. One hour of IAAP volunteer service (outside of committee work) = 1 CAEC
   3. Please note: Volunteer engagement is capped at 15 CAECs per year.

To sum it up, the IAAP’s wants you to earn your CAECs through the Professional Development category. This is the only category where each hour of your time is granted one whole CAEC, except for the option where you can sign up to volunteer for the IAAP itself, which also grants you one CAEC per hour you spend.

Rian’s feedback, that her paid work for open standards and public distribution should count for CAECs, and I fully agree. She met with an IAAP representative and it seems they will make steps forward in this regard. It’s much needed, and I really hope they listen to her feedback.

Besides this, I still have a few other complaints.

For the Professional Development category, basically the only realistic category in which people can rack up points, has a heavy location bias. When I was doing research for this post, I found one of the IAAP folks saying that they managed to achieve their year’s credits by attending one lunchtime webinar a month, implying that it was that easy. Do you know what time that lunchtime webinar is at for me? It’s 1am! I am barely holding back my rage here.

I live in a place where there aren’t really any local or far-but-timezone-appropriate events I can attend during normal working hours. I’m mostly limited to online, live-streamed events that I can watch later. And I’m so grateful that there are at least a few free options to choose from. If Inclusive Design 24 and axecon didn’t exist, I probably wouldn’t have a way to get enough CAECs without shelling out for IAAP’s own paid webinar series.

As grateful as I am that free resources exist, I can’t count the number of times I’ve sat through a thinly-veiled product advertisement or an Accessibility 101 talk for a CAEC. I can’t help but wonder if there are better uses of my time. To put it frankly, I don’t really know how much time I have left on this earth, but I do know that I want to spend as little of it as possible in yet another webinar that I don’t care about.

Which brings us to our second point, the Sharing Your Knowledge CAEC requirements are so strict that they are functionally useless. I’ve never written a book, but I’m sure it takes more than 5 hours. If you’ve organized an accessibility conference but aren’t the number one lead organizer, you’re out of luck.

If you are paid for any of this work, this means it is invalid for CAECs. As a freelancer, I have no company behind me that will sponsor my presence at any events. If I choose to speak at an event, I may receive a stipend that would cover 1/10th of the hourly rate I would charge if I were doing development work, and somehow, this invalidates the CAEC.  I get it, people who are sponsored by their organizations shouldn’t get a free pass at a certificate renewal, but this seems like an unnecessarily strict boundary, as Rian pointed out.

Additionally, the other work that is deemed appropriate for the CAEC is just… completely out of touch with what web accessibility experts do. Forgive me for tooting my horn for a tiny bit, but I have:

• Written blog posts that are referenced by multiple governments around the world
• Written a posts for publications that reached hundreds of thousands of page views, for which I received a nominal stipend equivalent to one or two hours of my normal rate
• Conducted free (publicly documented) accessibility testing for a variety of products and organizations, leading to more accessible products used by millions
• Contributed to the A11y Project, including a substantial rewrite adding dark mode to the site

Honestly, this pales in comparison to the amount of work other folks I know do. I’m only really a ‘few times a year’ blogger at best, many folks I know publish on a regular schedule. Not one of these accomplishments would count for a single CAEC. The requirement that blog posts be in a series of five is honestly baffling to me. I honestly believe that some of the most important pieces of accessibility writing ever are in the form of single blog posts. There are many, many blogs by accessibility experts who I consider required reading for entering the field, and none of this would count for any ‘Sharing your knowledge’ CAECs! I can’t even tell you the last time I read an academic accessibility paper as part of my day-to-day work, but I read accessibility blog posts every single day.

The failure to include open-source work also feels like a glaring omission. The WAS certification is described as a certification in technical digital proficiency, it’s just weird to me that doing the very same work for free is somehow not included. There are some people I know who refuse to get the certification because it would take away time from their ability to do work with actual impact, and I respect the hell out of that position.

My conclusion about all of this is that the IAAP does a very good job of promoting accessibility as a money-making business, but not as a field. Why else would you even consider any form of co-operation with overlay companies? The Professional Development CAECs are all in easily monetizeable forms, and lead to partnerships with those offering academic courses or paid conferences, even if they don’t relate to how most of us actually stay on top of the field.

Adventures on the IAAP site

The final thing that inspired me to write this post is the absolutely horrible time I had trying to submit my CAECs. I’m not exactly sure when, but at some point, the IAAP moved over to a new portal system to submit the credits.

Upon navigating to the portal, I was greeted with this login form.

You might think those grey boxes represent inputs, right? Ignoring the fact they use the problematic ‘placeholder text as label’ technique, there is already a Non Text Contrast violation in the fact that the input border or background color don’t contrast enough against the page background.

The reality is actually much worse! This white rectangle isn’t an input, the actual input area is a tiny rectangle within the boundaries of the white box, featuring a focus outline that does not meet contrast requirements! People I know who wouldn’t dare call themselves accessibility experts out of respect for the field wouldn’t even make this mistake!

Once you’re in, the process to submit the CAECs is such poor UX that I may have burst a blood vessel while trying to fill the form in. There is a rich text field to list out what activities you participated in. Since some activities are officially preapproved for CAECs, if it were me I would have made some kind of user interface where you could select a provider, then check off a list of checkboxes instead of having to type it up and calculate the total number of hours yourself. It would probably speed up the process on the validation end too. But this next step is the part that really got to me.

The previous page informs you that there will be a place to upload the associated files to prove you’ve participated in whatever activities. Why they aren’t on the same page, I’m unsure. When landing on the next page, this is what I see (I’ve blanked out some information here.)

“Aha, the Files button, that must be it!” I thought. But upon clicking it, I realized my mistake, this was actually not the button that allows you to upload files, which is in a section much farther down the fold. This is in fact, a link, and upon clicking the entirety of your forms progress is lost, an experience so frustrating that it caused me to write this 2500 word blog post on a Friday night.

I genuinely don’t like to nitpick people unnecessarily, I think it can hurt well-intentioned folks trying to learn. But if you are judging us on our accessibility, I do believe that gives us the right to judge you back. I find it a bit embarrassing that the organization that certifies accessibility experts has such obvious accessibility errors that can be detected with even a superficial glance.

The accessibility field already struggles with the ‘divide’ between experts and disabled people. With a test that has an ableist focus on rote memorization, a re-certification process that adds additional burden onto a group that may already struggle with having enough spoons to do unpaid work, and an inaccessible website, it sometimes feels like the IAAP just widens the gap between practitioners and the disabled people they’re meant to serve.

To come back to the original question, I’m still on the fence about renewing my certification. I don’t do a bunch of enterprise or government work so it’s been less useful than I would have hoped. I would rather work with people who already vaguely know who I am and what I bring to the table, but the fact that I would have to take the exam again to regain the certification is definitely holding me back a bit. There is probably enough relevant, on-demand content that I was going to watch anyway to squeeze out another renewal, but I would never judge an accessibility professional for choosing to forgo the certification.

Related reading

• The IAAP re-certification process is but one pain point that Lea Rosema has with the field
• I linked this earlier, but Karl Groves point needs to be shouted from the rooftops.
• Adrian Roselli briefly mentions why the IAAP certs are tainted in his eyes
• Erin E. Perkins made a post about CAECs on LinkedIn, with some official responses in the replies. (Thanks Rian for bringing this to my attention!)

Goals

Given Marianne’s previous background, it seemed only logical for our theme to target the high-end market. There aren’t many all-women teams in the Shopify theme space, and we felt that we could bring not only our professional experience, but our personal experience as the target audience for the kinds of brands we’d be hoping to reach.

While we definitely wanted to make our theme easy to use for the average merchant, we also had a secondary core audience in mind, agencies and other developers. Over the years, we’ve spent a lot of time customizing premium themes for various merchants, and we have a strong idea of what makes a good foundation for that kind of work. Essentially, we wanted to build the theme for the past versions of ourselves.

As we are both perfectionists, our core philosophy was “we will spend the time obsessing over the details so other people don’t have to.” One example of this is is the infinite loading option on the collection pages. Although we definitely have mixed feelings about infinite loading, we know that regardless of how we felt, people would want this feature anyway (more on this later), and if it was going to be done, it had to be done well. We looked really carefully at dozens of different implementations and all their pitfalls, and our solution manages to:

1. Preserve back button state
2. Utilize real <a> tags that are swapped with the more semantic <button> element to provide search engines with paginated URLs
3. Supports progressive enhancement in case JavaScript fails to load
4. Communicate state and manage focus for non-mouse users

We took this level of care with every single part of the theme. We even had a huge multi-hour fight about what to do when someone typed a decimal place in a price input from any given locale, that’s how deep we examined every component. Building a solid foundation was extremely important to us throughout the process of building the theme, as we have a lot planned for the future. From day one, we brought advanced features such as right-to-left support and cart upsells, but there is still plenty more features that we want to add.

In contrast to the standard SaaS product and similar themes, we feel that the end product of our theme isn’t just the end-result that the user experiences, it’s also the code that underpins it. Developers and agencies should be able to extend the theme easily, they should be able to configure a few design tokens or change a few settings to get all of our powerful functionality with a unique look and feel.

Yes, it should be easy to get up-and-running, but it should also be easy to take that design and run with it. I’ve been in that place where I have to just change one font size throughout the store, and the lack of a design system or component based architecture means that what should be a 5 minute task becomes a 3 hour task. Not fun, and certainly not something we wanted to deliver to our fellow developers.

Tech

Because we want our codebase to be something that people can easily extend, we had to think really carefully about the tech stack and dependency tree. We settled on an architecture where we concatenated our core CSS and JavaScript into one big file, but we left it un-minified and used no other tooling. For the perf geeks out there, don’t worry! Shopify minifies the code before it serves it, but the code that developers see and access in the editor is unminified.

That meant that all the CSS is just vanilla CSS with no frameworks, and all the JavaScript bits are Web Components/HTML Custom Elements. Before this project, I had dabbled in Web Components for one-offs, but never for an entire project of this scale. To steal the lexicon of a finance bro for a second, I’m now incredibly bullish on Web Components. Their extensibility is unmatched, if someone wants to take most of your behavior and add their own behavior onto it, they can simply extend the Custom Element and override or enhance the necessary methods.

Web Components don’t ever need to be upgraded, and they’re a part of browsers so they have to support them until the end of time. Because the Shopify theme store involves a one-time payment for lifetime support (much to the chagrin of theme developers), anything to minimize our support burden would be important.

In terms of third party dependencies, we only have two JavaScript libraries in the theme. The first is What Input, which tracks the current input method. We use this to iron out inconsistencies with how browsers handle :focus-visible. One major thing that came up is that Safari showed :focus-visible upon programmatically moving focus. Because so much of the code relies on the Shopify Section Rendering API (which is basically Shopify’s take on HTMX, it helps you swap out bits of HTML as interactions happen), we have to move focus to the newly rendered HTML quite a bit, and it was often confusing for a focus ring to suddenly appear after a fetch request that is supposed to be hidden to them. However, we’ve still kept the ability to disable it easily if you want to use the native :focus-visible detection.

The second third-party dependency we use is the instant.page library (which can be disabled, of course). This helps to speed up requests by prefetching the next page when it detects user intent to navigate. In the future, I hope the speculation rules API will replace the need to include this at all, and we can get rid of it entirely.

To dive into Shopify specifics for a bit, I’m really proud to say Primavera is one of the first themes to utilize the new Theme Blocks architecture. The previous architecture before this is generally called Online Store 2.0, and it comprised of sections (think, a hero section, a list of products, etc.), and a single layer of blocks, which could be more granular components, like a button, but also larger ones like a slideshow slide.

This single layer limitation was extremely limiting. Take our slideshow example, having the Slideshow be the section and a Slide be the block meant that there wasn’t flexibility for determining what was in the slide without a bunch of duplication. This meant that there were a ton of arbitrary limitations on design, like a slideshow slide would pretty much consist of a subheading, a heading, text and a button, with no possibility to change the order.

With theme blocks, you can nest blocks up to 8 levels deep, which means that you could compose blocks out of other blocks. This unlocks tremendous possibilities for design, and it means a better surface for other developers to extend the theme. If you wanted to add a block unique to your store, you could simply add it as a block, and then you could use it in any section or block that you wanted, whether it be a hero section, a card, in tabs, an expandable element, etc.

There are still a few kinks to work out with Theme Blocks architecture. We’ve had issues with third-party apps not supporting it yet, there’s limitations on variable scoping, and there’s no way to set a limit for how many times a theme block appears. However, I truly do believe that Theme Blocks are the way forward for the Shopify ecosystem, and I’m excited to be at the forefront of those using it. (Edit: We’ve just published a deep dive into our use of theme blocks that might interest you if you like this post!)

The end result of all these technical decisions is hopefully, a codebase that is very much human-readable, but easy to extend. Those who’ve worked with Shopify before know how elusive that perfect 100 lighthouse score is, and we’ve managed to build something that can achieve it (with careful and well-considered use of media, of course!) We really hope to provide a good foundation that will scale as merchants do.

Accessibility

Readers of the Blog will probably know that I will not shut up about the accessibility of Shopify themes. E-commerce as a whole is an incredibly inaccessible part of the internet, and I felt that my unique background as an accessibility consultant and a developer could bring about greater impact if I tried to ‘shift left’ in the process.

As a result, it was always a huge priority to make things accessible, and building the theme has been a delicate balance of trying to manage merchant expectations with creating an accessible user experience.

For example, if it were completely up to me, I would personally not include a marquee text region in my storefront. I know the problems they pose to users, and I find them quite distracting as I read. However, our thinking was, if merchants were going to use marquee text, we had a duty to build the absolute best marquee we possibly could. This approach was later validated shortly after launch. We had intentionally chose to not allow a marquee in a particular section, but we saw the merchant had customized the code to add the marquee where they wanted it using using the deprecated marquee tag. Needless to say, this wasn’t a very accessible implementation.

Our marquee component has a pause button, respects the user preference for reduced motion, only enables focus for the first unique instance of a link, and only announces the first instance of the text. While there are certainly things that I think can be improved, a huge amount of effort was put in to make sure that disabled users would not be blocked by it. Marquees are not great for accessibility, but one that has considered accessibility is certainly better than one without.

The way themes are sold poses an interesting difference to my regular accessibility consulting work. In consulting, you are in direct dialogue with the merchant, you can talk to them about why a feature they want is inaccessible, and sometimes you can even convince them to adopt an alternative approach. With themes however, merchants just browse from a giant list. They will often expect a certain feature or design, without knowing anything at all about the impact on accessibility, and if the theme doesn’t have that feature, they will just move onto the next option.

Knowing this, one other technique we’ve used is an ‘escape hatch’ approach. We have features in the theme that technically comply with WCAG but do not represent best practices in accessibility, and we’ve tried to ensure there’s always a more accessible backup alternative for people to choose. We have my arch nemesis, text inputs indicated only by a single line in the theme, but we also have the option to switch to regular box inputs just by toggling a setting. We hope this will make it easier for merchants and the teams working with them to enable better UX choices without requiring a major rewrite.

In terms of future goals, while I’ve tested as much as I could on my own with the assistive technologies I have available to me, I really want to engage more disabled users for testing. We also want to get a third-party VPAT in order to better document where we are at and where we can improve.

A good accessibility consultant knows that perfect WCAG compliance is an incredibly lofty, even unrealistic goal, and that perfect, bug-free software will never exist. The best we can do is to promise to treat accessibility issues as seriously as we treat any other issue. I’ve been the person e-mailing software vendors them asking them to fix their software, only to be de-prioritized and ignored, and I do not want to be that person for someone else.

Timing

I’m generally pretty decent at estimating (10 years of timesheets will do that to you), but I did drastically underestimate this! Marianne and I had regularly turned out full theme builds from scratch in 3 weeks at the agency we worked at. However, I had failed to realize that building one single design is a much, much smaller task than building a system that can encompass many designs.

A lot of work went into building out many different configurations. In a single site design, you might be like, ‘ok, this product page will have 3 product images, all the same aspect ratio, how can we best present this’? But if you don’t know what your merchants are with, they could upload anywhere between one and a hundred images, some video, of mixed aspect ratio, etc. Thinking through these different variations took up a lot more time than anticipated.

We had hoped to submit our theme to the store in 2.5 months, but it ended up taking about 4 months to get the code done. The path was very non-linear, Theme Blocks architecture was in beta when we started, and it launched after we were about 95% done, at the end of January. We ended up rewriting our entire codebase to use Theme Blocks architecture after the first submission, a process that shockingly only took 6 days thanks to the modularity of our code.

I had also underestimated how much time it would take to get the non-code tasks done too. Styling and getting images for the demonstration stores took about a month and a half, and the fact we were trying to get our business up and running during the key dates of Christmas Holidays and Lunar New Year meant that the paperwork took longer than expected as well. We launched with a complete set of documentation for every one of our 30+ sections, and writing all of it up took up the better part of a month.

The submission process was totally unknown to us. All themes must be reviewed by Shopify, and the checklist of requirements is over 10,000 words long. We had heard it could take anywhere from weeks to months to hear back from the Shopify review team, and we also knew that it was possible that you could be sent back to the drawing board if your theme wasn’t uniquely different from others in the store. We were very grateful to get through the process in just under a month with only minimal back and forth, we knew the process was not smooth for most.

The overall process from start to finish took around 6 months on my end. Marianne had worked on some of the design and UX in her downtime from client work for over a year prior. During the six months of me being full-time on this project, there were many weeks where we worked 7 days a week, I took a total of two days off for the winter holidays. It was a completely unsustainable pace, and even a month after launch we’re still trying to recover from the experience. I took on a few small client projects during this time, but the lack of usual income meant that this was a significant investment of time and money.

I’d be remiss if I didn’t mention something about the current world situation. I am fully aware that the conditions for collaboration would have likely not happened in better economic times as Marianne and I would have both been busy with client work. However, the state of the tech industry is pretty dire, and the world economy seems to be on the brink of recession, with uncertainties about global trade looming over many businesses. You’d be hard-pressed to find a worse time to start something dependent on the success of mostly English-speaking merchants. Still, we have yet to come across a mechanism for time travel, so hunkering down and trying our best is the only thing we’ve got right now.

Advice

When I told people I was working on a Shopify theme, after clarifying that it was indeed not a Spotify theme, I would often be met with responses like “It’s such a good idea to work on a passive income stream!” As much as I’d love to lie on a beach somewhere doing nothing but check my bank account, I have to emphasize that the ideal end-state for us is to reach a place where we can work on this full-time. Because of the requirements of the marketplace, there’s not really a way to make this a form of passive income.

Shopify themes are not like selling other templates, for two main reasons: 1. the ecosystem is always changing. Shopify requires the theme be updated to support new features, and if you don’t meet the deadline, your theme will be delisted. You definitely cannot hit publish and then forget about it. 2. The price of a theme includes lifetime support. For several hundred US dollars, you need to offer lifetime support for your theme as long as it remains published. I’ve heard of theme partners receiving hundreds of support queries from the same person, for less than the price of a single month of an enterprise license. Potential theme vendors should keep both these things in mind before committing to the journey.

How’s it going?

We’ve been published in the theme store for about a month now. Sales were strong at first as we were featured in the much coveted homepage spot for new themes. As anticipated, once we lost that privileged position, we now need to split our focus between marketing and developing the product simultaneously. We’re working on building an audience and reputation that can sustain our business for the long term, regardless of whether or not we’re on the first page of the theme store. We know it’s definitely an uphill battle ahead of us, but after so many years of agency work, I’m excited to try living in product-land for a little while.

Shameless plug

If you’re interested in theme, you can visit our studio site or the Primavera theme listing directly to check it out! I’ve linked to Artistry, our most accessible preset out of the box, but I think you’ll be impressed with how easy it is to get entirely different looks by just tweaking the global settings.

Feel free to reach out to me at nic@ultramarinastudios.com to let me know what you think. I promise I have far too much anxiety to upsell you if you just want to geek out over the details! If you’re an agency or developer looking to see if Primavera is the right fit for you, drop me a message and we’d be happy to send you more information.

Why did you start blogging in the first place?

I’ve been freelancing for almost a decade now, and honestly, publishing a blog was an attempt at marketing. I don’t tend to write content that is particularly ‘clicky’, so I can’t say that I’ve done a very good job at it, but I have made some really wonderful connections through this blog, so I can’t say it’s been a total failure! I have had just one inbound lead reach out to me and mention the blog, but they’ve been a great partner over the years that shares my values,.

What platform are you using to manage your blog and why did you choose it?

I’m a huge fan of having your own personal site! My website is currently an Astro site, and every post is a .mdx file (as opposed to vanilla Markdown), just because I have an Image component. I’m still feeling like that’s a risky bet, we’ll see what happens by the time the next redesign comes around! You can read more about the decisions that went into this in this series on redesigning my website, which I still fully intend to finish, heh.

Have you blogged on other platforms before?

I would not blog if it were on a platform I didn’t control, it’s never really interested me. My desire to not be perceived is only occasionally overpowered by my passion for a topic. [insert two  wolves inside you meme]

How do you write your posts? For example, in a local editing tool, or in a panel/dashboard that’s part of your blog?

I really loved the tool Writerie by Michael Scharnagl! Now that it’s gone, I am still looking for the best place to keep all my posts. My main criteria is that it allows me to export to Markdown. I’m open to suggestions, let me know if you really love your blogging flow.

When do you feel most inspired to write?

My interest in blogging is fairly constant, but easily affected by inertia. This is probably slightly toxic behavior, but I usually only manage to get a post out quickly when I’m feeling riled up. Otherwise, I just let it sit for a while until I can give it a re-read with a fresh perspective.

Do you publish immediately after writing, or do you let it simmer a bit as a draft?

If you haven’t noticed, I’m very much a let it cook kind of girlie! The one thing you can count on is that I will always be late to a trend, so if I blog on a topic, I have to really make sure that something is worth reading, even after a hundred other people have written about it.

People who manage to publish quality posts on a regular schedule amaze me. I think I need to learn to lower the bar a little. Bloggers I regularly enjoy often let a typo or two slip through the cracks, but it’s not something that affects my perception of them. It’s probably worth letting some imperfection come through if I can publish more regularly than twice a year.

What are you generally interested in writing about?

Not to sound like a rebel, but the things you won’t find on corporate blogs. This isn’t to disparage those who publish posts on more popular subjects, it’s just that for me personally, I only really have the impulse to write when I feel that there is something missing from the discourse about a topic and I feel like I can bring my own unique spin to it. Since I’m pretty slow and my free time is limited, it’s unlikely that you’ll find me writing posts on the latest CSS feature, even if it is a subject that interests me greatly.

Who are you writing for?

Shout out to my RSS fam! I’m never really sure who my audience is, I think I just try to publish every once in a while to remind people that I still exist. The typical reader is:

• Interested in front-end web development or accessibility
• Cares about the web ecosystem
• Not very likely to hire me, despite the original intentions of this blog, lol

What’s your favorite post on your blog?

This one, What Tumblr taught me about accessibility is probably my magnum opus. It feels like something that only I can write, which is the goal for this blog. It still pretty much sums up my approach to accessibility, which is more person-centered rather than compliance-centered.

Any future plans for your blog? Maybe a redesign, a move to another platform, or adding a new feature?

I often toy with the idea of webmentions. I really like them in theory, I just feel like there’s quite a bit of a hurdle to jump through. I had them on a previous iteration of the blog, but when I changed the casing of my Twitter handle at the time, all my mentions disappeared, so I never bothered to bring it back.

Life updates

• I’ve been a part of the Grid-aware Websites (aka GAW) advisory board over the past few months. I’ve been delighted to get to work with the Green Web Foundation folks (particularly Fershad, Hannah and Chris), and all the other members of the advisory board. When the world feels like it’s on fire, it’s encouraging to show up to a room of people who really care about making it a little better. I hope to publish something on Grid-aware websites in the coming months.

• Switched some of my browsing over to Zen Browser! I still need to use Chrome for some tasks (I can’t seem to use Figma with my pointer device of choice, a drawing tablet), but overall I enjoy Zen, and I think it makes me a better developer to use non-Chromium browsers regularly. I did not like that I had to do some work/install extensions to get the scrollbar to show up in the UI though.

• Managed to get all my Kindle books files before Amazon decided to be an ass and remove that feature. I’m definitely not getting another Kindle once this one dies, but I’ve had it since 2017 and it’s still somehow going strong. It feels more wasteful to throw away a perfectly functioning device, even if I want to boycott the company that makes it.

• Been attending a lot of life drawing! I really enjoy it. I missed the entirety of the good plein-air weather in Hong Kong in my work-induced fervor, but this is something I can keep doing in the summer too.

Tag, you’re it

I’m technically supposed to tag someone, but since I’m over a month late to the trend, I had difficulties finding anyone who is a regular blogger left untagged! If you’ve been in a rut and want to get back into blogging, take this as a gentle encouragement to use this post format. Let me know if it gets you back into blogging and I’ll link you here.

Who is responsible for accessibility?

The original thread, and several spinoffs, are filled with anger at Shopify for not making their storefronts accessible. Some merchants are upset at the idea that they can personally be held responsible for accessibility, while admitting that they have never thought about accessibility.

One thing I’d really like to hammer home is that accessibility is affected by both content and code. You can have the most accessible theme in the world, and create immediate access barriers with your decisions. For example, you could pick inaccessible colors for your brand, you could write marketing copy full of ‘click here’ for every link, you could fail to write (AI-assisted or not) adequate alt text for your images, the list goes on. People willingly take the responsibility of designer and copywriter in order to avoid hiring an expert, but they don’t want to take responsibility for any harm that their ignorance might cause.

On the code front, it’s not uncommon to see merchants cobble together complex functionality based on apps. I get it, most people do not have the budget to hire web developers, and it is a sad fact of the web landscape that most websites and apps are inaccessible by default, with 96% of the top million websites having automatically detectable Web Content Accessibility Guideline (WCAG) failures. But at the same time, while it is true that the web is inaccessible by default, which poses a challenge to those trying to do right, many merchants explicitly admit to never even thinking about accessibility at all.

I like to think of this example as renting a commercial space. The building may have been constructed in accordance with local fire regulations, but once you put your furniture in, and do a little DIY construction on the side, it’s entirely possible that you’ve created something that violates local fire regulations. Does that make the landlord responsible for the violations because they rented the space to you? Does ignorance of these fire regulations mean that you aren’t obliged to follow them?

Generally speaking, in the United States, the company (in this case, the merchant) is regarded as legally responsible for accessibility. You can read more about it in the Converge Accessibility blog post titled “Can Web Developers be Sued for the Inaccessible Sites They Create for Clients?”.

I have genuine sympathy for vendors in that it is hard to do things correctly while wading in a swamp of poorly constructed themes and apps. It can be devastating for a small business to be hit with an expensive lawsuit, especially in the case of the original poster, where it seems like they did actually consider accessibility to the extent which they were able to. I’d like to see the legal process become more remediation focused rather than settlement based.

But I do think the desire to never think about accessibility personally, to dump that responsibility onto someone else, has negative impacts on the accessibility of the internet as a whole. It is an attitude that harms disabled people on the internet every single day.

How can I figure out if something is accessible?

Not enough merchants are aware of the existence of Accessibility Compliance Reports (ACR), which provide a useful tool for assessing accessibility. While most merchants never think about accessibility at all, those who do might search a marketing website for keywords such as ‘accessible’, and then take that at face value. Adrian Roselli has written extensively on why one should be wary of superficial accessibility guarantees from vendors. Oftentimes, the marketing team or sales team is simply not on the same page and may provide false claims.

A particularly egregious example of incorrect accessibility claims can be found in the original Reddit thread. The original poster says that upon reaching out to Shopify support, they were advised by the Shopify support staff to install an accessibility overlay tool. Those in the accessibility industry know that Accessibility Overlays Don’t Work, and I’ve personally come across a case where the presence of an overlay tool blocked all screen reader users from being able to reach checkout. You know, the primary function on an e-commerce site. Yikes. I would really like to see Shopify do some kind of internal training to ensure that the support staff are all on the same page with regards to accessibility issues.

As a developer and not a lawyer, I’m not really able to look at an accessibility policy or accessibility guarantee from a vendor and draw meaningful conclusions about legal risk from it, but an ACR consists of technical information on how a product meets the WCAG success criterion. The presence of one or multiple ACRs by a vendor is generally a positive sign for accessibility. It means that an organization has at least thought enough about accessibility to invest some resources into producing the document.

There are certainly still issues with ACRs, as Brian DeConinck outlines in this post ‘What’s wrong with VPATs?’. To summarize Brian’s post, ACRs may often be seen as another arm of the marketing department, and it can be tempting to construct the ACR in a way that minimizes the number of issues found, either by reducing the areas of the site that are tested or by excluding specific assistive technology.

Truthfully, as an application grows in complexity, it is more likely to have accessibility issues. In an ACR, each WCAG criterion can have a corresponding conformance level: supports, partially supports, does not support, or not applicable. You would think that finding an ACR with every criterion marked as ‘supports’ is a good thing, but it can indicate that a vendor is more interested in having a ‘passing’ ACR rather than an accessible product. When I look at a ACR, I’m not looking for legal risk, I’m looking for the depth of information provided about the usability, and that means diving into the depths of ACR comments.

Final thoughts on Shopify

It is not my intent to defend Shopify or other large corporations, or to downplay the issues presented and the harm they may cause to users. Rather, it is to communicate the nuanced nature of accessibility. Although the guidelines lead us to think of accessibility as a binary, as ‘conforming’ or ‘non-conforming’, this couldn’t be farther from the truth. There is room for improvement in Shopify’s Dawn Theme ACR (and I’d like to see a newer one as this is almost four years out of date), but I appreciate the level of transparency in calling out potential issues, even if they are likely to affect a small subset of users, or are issues baked into the technology. They have also called out issues related to the software that their theme depends on, which is a level of responsibility that I don’t see many merchants taking.

When remediating Shopify themes, I feel confident recommending the Dawn theme to potential merchants. Compared to other themes, the issues with this theme are largely non-blocking, or can be avoided with some care. While it is always possible for any software to have regressions, the fact that there was clear effort in the past and a willingness to fix issues with the theme are positive signs in my book. Although we shouldn’t ignore the significance of non-blocking issues, an ACR like this indicates that there are a lot of things going right with accessibility. There is a level of intention here that I think matters a lot; you cannot stumble upon this level of accessibility accidentally, you need organizational backing to develop mature accessibility processes.

However, my review of Shopify’s accessibility is definitely not all sunshine and roses. I haven’t mentioned them much previously, but I’d like to call attention to the understated impact of third-party apps. Because they are so easy to install, it’s not always immediately obvious how devastating a single app can be towards a storefront’s accessibility. Any single app that touches the storefront can block the user’s ability to achieve their goals. While Shopify’s first-party themes may have done a decent job, they continue to run an app and theme stores that is largely filled with inaccessible apps, simply because it is profitable.

In a way, the Shopify app store and theme store create a parasitic ecosystem. Shopify gets to wash their hands of the responsibility of building all this complex functionality by themselves, and the third-party apps and themes earn them money without being subject to stringent guidelines and scrutiny the way first-party code is. I remember a time when there were discussions about implementing accessibility requirements, but it’s been several years and they have yet to come to fruition.

I’m a merchant and I want to do better, where should I start?

I don’t think there is any single thing one can do to avoid this kind of drive-by accessibility lawsuit, but the best thing you can do is to put effort into accessibility from the start. Knowing what accessibility is and trying to think about it as early as possible is always a good idea, and may potentially help you in getting frivolous lawsuits dismissed. An accessible theme is just a starting point, and in the end, it is the merchant’s responsibility to consider accessibility throughout the process.

In terms of cost, it is always cheaper to think about accessibility up front. A remediation job of an inaccessible site can take a skilled developer hundreds of hours. I know that auditing third-party vendors for accessibility is not a skill that everyone has, but short-listing a bunch of potential themes and apps and then consulting with an accessibility professional for a few hours is far cheaper than waiting till you’ve already been sued. Maybe, while you’re at it, you can even work on an accessibility statement together, so disabled people know where to turn to when they need assistance.

When the only recourse available to people with disabilities is to sue, class actions get attention.

• Sheri Byrne-Haber

As a final note, I can’t state enough that disabled people shouldn’t have to beg for accessibility, but the current state of accessibility legislation means that disabled people are often forced to rely on complaints and lawsuits. Asking nicely doesn’t alway work, and so, we’ve created the current adversarial state of affairs. A certain percentage of lawsuits are frivolous in that their claims are unsubstantiated, but until something changes, lawsuits are one of the few tools disabled people have in order to be treated equitably. Before complaining about frivolous lawsuits, I have to ask, have you done your part in making your site accessible?

Full text RSS

This was really where progress on the site began to stall. At the time I was building this out, Astro had no support for full text RSS out of the box, and there were several hacks, (another hack) that would let you bypass this, but I really didn’t want to bother when I felt like the Astro Container API was going to happen soon. Luckily, my guess paid off, and Astro released the Container API, which worked without a hitch! Sometimes procrastination pays off!

I did hit a minor snafu in that the Astro RSS Feed plugin only outputs RSS format, not Atom. I wanted to use Atom to leverage the ‘Updated’ property in my posts, as I occasionally need to make corrections and revisions. Luckily, I was able to switch out the plugin for the framework agnostic feed plugin, which is both more flexible and has more features.

I really dislike the trend where every new framework needs to have it’s own version of a basic functionality. While there are definitely valid reasons behind the phenonmenon, I feel like it does end up fragmenting the web ecosysytem and gives junior developers the false impression that some things are much more difficult than they actually are.

Pixels, revisited

While creating new pixel sprites, I noticed that the file sizes were much larger than SVG sizes I have seen in the past. Some of them were over 30KB for a single sprite! This was because my pixel art program, Aseprite, exports every single pixel as an individual rectangle, even if the individual rectangles make up a larger blob of color.

I tried using PNGs while relying on image-rendering: pixelated, a technique recently outlined by Chris Coyier in more detail over at Frontend Masters, but I noticed that at the sizes I was displaying the image, it would sometimes render line-widths inconsistently. After the time I took to hand-pixel everything, there was just no way I was gonna let this slide.

Luckily, I found this really cool codepen by Shaw that converts a raster image into an SVG, so I ended up running everything through there instead. There’s a code version of this library that does this, but since I only have fewer than 10 individual sprites, it would have been overkill to implement.

As a side note, this serves as a gentle reminder to myself to ask for help sometimes. Upon looking at Eric Meyer’s library solution, I noticed Amelia Bellamy-Royds was listed as one of the contributors. I practically have Amelia on speed dial for all my tricky SVG questions, had I asked for help I might have saved myself many hours!

Once I had my SVGs, I cobbled together a quick Node script based on this helpful tutorial by German Makarov in order to glue them into a big spritesheet that will allow me to minimize the HTTP requests for the icons. I know there are plugins like astro-icon that handle this in a more ‘elegant’ way, but given that there is a pretty manageable amount of icons, I opted for the path that was much less likely to involve breaking dependency upgrades. Lately, I’ve been just writing node scripts for various build things if tooling feels too much overhead. I typically only dramatically change my site every 5 years or so, so having a maintainable, low-key solution is really important to me. I’ve suffered through enough Grunt, Gulp, Snowpack, Webpack and Rollup migrations!

Build-time generated table of contents

Having a table of contents generated at build wasn’t always easy to implement. It’s not uncommon to have to resort to client-side JavaScript in order to scrape the rendered content for headings, and this can sometimes be really undesireable due to the potential layout shifts, as Table of Contents are often relatively high up on a page. Astro makes this super easy by providing a list of headings already, and with some finangling with a snippet from Kevin Drum’s tutorial, I was able to get the headings in a nested format. It only took a little client-side JS to hook up an Intersection Observer to watch the content and highlight the section we’re currently on. Rendered HTML with a little sprinkle of JS for extra functionality, just the way I like it!

My approach to personal sites

This year has been pretty difficult in that I haven’t been able to do a lot of work that fully reflects my values. I have always wanted to build things that are cool and awesome without sacrificing the core values of progressive enhancement, performance and accessibility, and I’m glad that 1. that approach still resonates with so many people and 2. that I have somewhat managed to succeed in this goal! The idea to build an OS-themed site is certainly not new, but there aren’t a lot of them that don’t have a load screen, that work without JavaScript and on mobile-sized screens, so it’s been fun trying to solve those challenges.

I’m really glad to have a little space on my own where I get to explore new advancements in core web technologies and finetune my approach to the craft of making websites. There are still things I’d like to do with the site, but I’m trying to treat it more like a garden — just because things might change and grow over time, it doesn’t mean that it isn’t beautiful and worth looking at in it’s current state.

Thanks, EJ

I wanted to give a shoutout to my good friend EJ Mason for their unwavering support, and willingness to discuss accessibility issues and look at things in Safari, my worst nemesis. The process of getting this done was spread out over a year, stuffed between busy periods of client work, and I can’t thank them enough for being there throughout the process.

What’s next?

One of the reasons I decided to stop tinkering and hit the publish button was effort of maintaining two versions of my blog simultaneously. It was really holding me back from publishing more in a way I didn’t initial expect. I have a few drafts in the backlog that I’m excited to share, and I intend to finish up the series on building this very site, if only to document some of the cool new things we have in CSS that I learned along the way! I hope you’ll stick around for the journey!

(PS: I really hope I didn’t break anyone’s RSS feeds by migrating! Please let me know if I did!)

Blog page

Whenever I’m feeling like progress has stalled on a progress, I try to work on things that I know are quick wins. In this case, it’s making new pages! I throw together the main blog and blog tag pages really quick with components and layout primitives that have already been built. Finally, I feel like I’m at the point where things just flow together based on previous work.

I have added a component for the a11y-webring.club. I’m not presently a member but would like to join once I get my new site running. Membership requires a public accessibility statement, so I make a mental note to draft one at some point.

Theming

I do a whole bunch of work with the color variables to flesh out the light and dark themes a bit more. The new light-dark function puts in a bunch of work here, and I’m really excited we no longer have to use mixin based approaches in order to manage this without unneccessary duplication.

Code styles

I was delighted to find that Astro comes with code syntax highlighting out of the box, but unfortunately, none of those out of the box themes met contrast requirements. Making accessible coding themes is very difficult, as you want the colors to have enough contrast between each other, as well as the background, but also, not be so jarring that it’s hard to read. I found this online tool for making VSCode themes and I just quickly slapped some of my website colors together so that I could at least have something that worked for the blog.

Blog post styling

Back to the more difficult task of sorting out the blog post content. I have a few things that I need to sort out when migrating my blog post content. First up, I have some small HTML pieces I need to style. This isn’t too bad either way, just a matter of adding CSS to those classes, phew.

I also need to convert my Cloudinary image Nunjucks snippet into an other format. I consider it necessary for performance to serve responsive, optimized images to the end user, and I used to rely on my Cloudinary Nunjucks snippet to do so. Although Astro does support optimizing your local images automagically in markdown, and the documentation currently implies that it does also do this for remote images, an Astro team member has informed me that it is currently not the case.

Astro does support MDX out of the box, which let me use components (framework or web) in my post, but I had noticed that it would make it an order of magnitude more complicated to output the full post in your RSS feed if you used MDX. In short, Astro exposes a method to get the HTML from a post if you’re using vanilla markdown, but not MDX. This is the first time I’ve hit major limitations with Astro, which is not unexpected (every framework has limitations!), but it definitely took the wind out of my sails.

Further complicating matters, a small handful of my posts have some minor scripting. This is small things, like a button to slow down videos, and a transcript that has timestamps that link to the player. The use of View Transitions and Svelte hydration means that making this all work is much more difficult than dropping 20 lines of script into a blogpost. I tinker around a bit with adding event listeners for component mounting and page swapping, but the Youtube player example is especially finicky due to requiring an external script event as well. In the end, I decide to ditch the linked transcript numbers, and opt for converting the little demo videos into a Web Component for greater portability in the future.

Disabling copy and paste / password managers

It’s become increasingly common to see sites preventing copy and paste on password fields. Nicholas C. Zakas has written an extensive blog post on why this pattern is a bad idea in terms of security. The newly formalized Web Content Accessibility Guidelines (WCAG) 2.2 has added Success Criterion 3.3.8, which explicitly mentions support for copy and paste as well as password managers as valid mechanisms for satisfying this criterion.

Blocking copy and paste often has the effect of blocking password managers as well. I’m sure I don’t need to go into detail about how frustrating this can be for password manager users, who often use those password managers to generate long passwords of random alphanumeric strings that they now have to type in character by character. Logging in, a process that should take me 10 seconds at most, can take up to 5 minutes of painful trial and error.

For example, the mobile banking app for DBS blocks copy and paste on the authentication screen. They’ve also disabled the default keyboard in order to show their own keyboard instead, which uses their brand’s red lettering on a white background. This color scheme does not mean color contrast requirements, and even I, someone with decent vision, struggled to read it. I would include a screenshot here, but they’ve disabled the ability to take screenshots of their application.🤷

For voice dictation users, disabling password managers is even more disastrous. The voice dictation software Dragon is a hands-free experience that works entirely by the user dictating voice commands to the software. A loose example (not actual Dragon) of a command might be something like ‘Click [Password Manager] Extension’ > ‘Search [Bank Name]’ > ‘Choose second item on a list ’, which would populate the username and password fields automatically. By disabling copy and paste, the user is instead forced to dictate their entire password out loud, which means that a Dragon user must be in a place where no one is within earshot in order to maintain a reasonable expectation of privacy.

What’s worst of all, in contrast to what the application authors intended, disabling copy and paste and password managers may actually have a negative impact on security as it encourages the reuse of passwords. Though there is increasing public awareness on why password reuse is bad, people are unlikely to change their behavior until the alternative is easy, and right now, it’s definitely not easy.

CAPTCHA

A CAPTCHA is a type of test employed by web developers to be able to tell if the user is a real human or a robot. These days, it is rarer for users to see CAPTCHAs in the wild due to widespread adoption of reCAPTCHA v3, a service by Google that claims to be able to detect malicious actors without requiring an interactive challenge. Privacy concerns aside for a moment, it can be difficult for behavioral based heuristics to distinguish disabled users from bots. For example, a screen reader user may come across as a bot due to not having normal mouse movement. However, due to the legal compliance and privacy issues arising from using a third-party service, banks that have a CAPTCHA often roll their own solution, which may not be tested comprehensively with disabled users.

Traditional CAPTCHAs display text that is partially obfuscated, asking the user to decipher the text. If a site is using this type of CAPTCHA, at a bare minimum, some kind of audio CAPTCHA is required too, as blind screen reader users will not be able to parse images of text. Much has been said about the inaccessibility of CAPTCHA mechanisms, as detailed in this thorough report by the Accessible Platform Architectures Working Group, but in short, CAPTCHAs provide major blockers to users with cognitive disabilities or sensory issues. Remembering an audio CAPTCHA string can be tricky and frustrating if the user needs to toggle back and forth between an input and a play button. Image and text CAPTCHAs are intentionally made to be difficult to read.

With Artificial Intelligence (AI) gaining traction, there is no question in my mind that there are malicious actors actively training AI to be able to solve CAPTCHA challenges. We maybe looking at a future where AI will be able discern CAPTCHA content much better than most humans, so we need to be looking at alternative solutions that aren’t based on people’s ability to discern and perceive.

Two-Factor Authentication (2FA)

Though they tend to be better than CAPTCHAs, Two-Factor Authentication (henceforth abbreviated to 2FA) solutions often pose different types of challenges to disabled users. There are various ways in which 2FA typically works, but the most common format by far, with over 90% of sites using this method is SMS, where a code is sent to you via text message and you need to enter that same code on the application. Email is also common, with specialized authenticator apps coming a distant third. These solutions do pose a similar challenge to voice dictation users as mentioned above, although the security risk is somewhat mitigated by the one-time nature of these temporary passwords.

2FA solutions almost always have a strict timeout, with some being as short as 20 seconds. Asking users to memorize arbitrary strings can pose a challenge for users with cognitive disabilities, and the short time limits are often frustrating to all users. I’ve yet to see a 2FA solution that allows the user to extend the the time as required by the 2.2.1 Timing Adjustable. Having an option to generate a new code may not be a sufficient replacement as the time window may be so short that a disabled user can never complete it within the allotted time.

The fact that these 2FA solutions often require the use of multiple devices can be problematic. If a blind user is using a computer and needs to also use a mobile device to receive an SMS, they may need to switch their headphones over to the mobile device in order to listen to the code. Furthermore, some assistive technology setups are so specific that users may be limited to a specific device, such as certain kinds of Braille displays that may only work with one primary device.

Blocking keyboard events

I had a enlightening conversation with a blind developer who banks at First Foundation Bank. They informed me that the bank’s web app directly interferes with or obfuscates the output of a keyboard, making them unable to use a screen reader at all with the application. Even though this user is an expert screen reader user and a web developer, they have call in to complete any banking services.

From the outside, it’s hard to know why First Foundation Bank implemented such a feature, but it could be possible that the bank thinks that preventing all keystrokes outside of designated inputs would prevent them from certain kinds of bad actors and security issues. It could also be the inadvertent result of a poorly crafted application that has not undergone screen-reader testing. Setting something like role="application or aria-hidden="true" can easily cause an application to be completely broken or hidden for screen reader users. Either way, be careful about making drastic application-wide overrides of keyboard behavior.

Lack of feature parity between desktop and mobile apps

(This point is less about security, and more typically about teams trying to reduce complexity across different digital products, but I thought it was worth mentioning anyway.)

I recently received an email from HSBC noting that they were discontinuing services from the web application, and moving them exclusively to the mobile application. The discontinued features included key services such as setting an overseas ATM limit, activating a credit card, and settings for quick transfer limits. As mentioned previously, some kinds of disabilities require specific assistive technologies, and it’s not always possible for users to switch devices with ease. If at all possible, it’s always better to make sure key features are available on as many platforms as possible.

Conclusion

For many disabled people, the internet is a vital way to stay connected and retain some measure of independence and autonomy. Banking applications have an extra responsibility to ensure their their services are accessible as possible and to think through new security measures extra carefully before implementation. If you absolutely need to make a process more difficult due to security reasons, provide multiple pathways for a user to complete the task.

Hurrah, it lives

At some point, I managed to get a deploy going on Netlify so I could be sure that the whole thing actually builds. I’m not exactly sure when this occurred, but I am very proud of my past self. I’d much rather debug a build as the process goes along, plus it gives me something to show people.

CSS Logical Properties

I suddenly remember that I want to switch over to CSS Logical Properties. I know I’m a little behind the curve on this one. I do often work on projects that involve Chinese, a language that can also be displayed vertically, so I want to try learn this ASAP. It’s a pretty easy conversion, but I do get stuck on if I want to set widths and heights using logical properties. I’m not entirely sure I want to account for re-orienting this very complex window layout, so I just focus on the text properties for now, to treat this as a learning experience.

Testimonials

I build out the testimonials section in the style of a chat interface. After spending so long tinkering on little things, it’s nice to do some CSS work where the little things fall into place! Note to self, go ask more recent clients for a testimonial.

Blog post styles

I’m at a point where I’m starting to work on the styles for my long-form content. I spend way, way more time on this than I want to, but I am really picky about these things. It’s all little things like tweaking the heading colors, the list styles, things like that. I love a good personal site where the text content just feels super polished and thought out.

I somehow find myself spending a significant amount of time working on the windows, again. There are slightly different behaviors for the windows based on things like its state (whether it’s minimized, maximized, or in its default mode), the size of the viewport and whether or not there are other windows present on the screen. Plus, each window accepts a wide variety of positioning and sizing props, which still need to work responsively. Getting all those combinations right is gonna take up even more time than I thought. I make a mental note to check in with some accessibility friends about the expected focus management behavior.

I really want to make a table of contents. I know I’m VERY rambly and therefore it’s nice to have a link to all the headings somewhere, but I realize that I need to build yet another window configuration if I’m to make it work. This variation on the window is positioned absolutely on middling screen size viewports, but centered on super large viewports. I get really sad that I can’t use CSS variables in media queries, this would make this an extremely elegant way to handle this, but I end up just going with a number that works for now.

Shortly after finalizing this approach, I make a breakthrough on a grid-based approach that I had experimented with and abandoned prior. I was having trouble making sure the contents of my windows would scroll within their containers, but I realized I just had to keep it simple and remove the absolute positioning from the grid children. D’oh! I adjust the blog post and about pages to utilize this new layout, which looks nearly identical but it pleases me to have a more elegant solution that looks better on more screen sizes.

Refactoring the SCSS Mixins

Here, I had another breakthrough and realized I could simplify my pixel borders. I was using this pixel borders SCSS mixin, and my major gripe with it was that it didn’t work with CSS properties, due to being written in the SCSS age. The mixin also supported different levels of roundedness, and I had decided pretty early that I on that I only want a single ‘pixel’ chunk cut out of each corner. This means I could replace all of this:

@function str-replace($string, $search, $replace: "") {
	$index: str-index($string, $search);

	@if $index {
		@return str-slice($string, 1, $index - 1) + $replace + str-replace(str-slice($string, $index +
						str-length($search)), $search, $replace);
	}

	@return $string;
}

@mixin pixel-borders(
	$color,
	$border-radius: calc(var(--border-thickness) * 3 + 1px)
) {
	$escapedColor: str-replace($color + "", "#", "%23");

	border-style: solid;
	border-width: var(--border-thickness);
	border-color: var(--border-color);
	border-radius: $border-radius;

	border-image-slice: 2;
	border-image-width: 1;
	border-image-outset: 0;
	border-image-source: url("data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' width='6' height='6'><path d='M0 2h2v2H0zM2 0h2v2H2zM4 2h2v2H4zM2 4h2v2H2z' fill='#{$escapedColor}' /></svg>");
}

With this:

@mixin pixel-borders() {
	border: var(--border-thickness) solid var(--border-color);
	mask: conic-gradient(
			at var(--border-thickness) var(--border-thickness),
			#000 270deg,
			#0000 0
		) 0 0 / calc(100% - var(--border-thickness)) calc(100% - var(--border-thickness));
}

I took much inspiration from this great article by Temani Afif. Thanks Temani, you really saved me on this one!

At this point, I contemplate moving off of SCSS mixins briefly. I am not against utility classes and have a couple myself, but I’m using mixins primarily for the pixel borders and focus outlines, and I may want them within blog post content. I don’t particularly fancy applying a focus-outline class to every single link in my text content, either through using a parser or manually. As a result, I conclude that mixins are helping me enough to survive this brutal round of code culling.

After doing a bit of cleanup, I come to the horrifying realization that CSS masks cover the outline property, which is needed for focus outlines. I read the spec to make sure this is as intended, and confirm that it is. It doesn’t feel great to me since it means a wrapper element is necessary when using masks on interactive elements to make sure you don’t completely break your outlines, but I accept this as a tradeoff.

With all this tinkering, I’ve probably spent an entire workday on changes that are basically completely invisible outside of a couple of niche cases:

1. the window arrangements don’t stack unnecessarily on small desktop screens
2. buttons don’t have this gross blurry border when subpixel rendering is forced (basically only if you’re zooming.)

It’s hard not to feel a little despair here at the time to effort ratio. I take solace in the fact that during the process of sorting all this out, I did a deep dive into CSS masks/clip-paths/mask-borders, and feel confident that I could apply them on future client work, so it’s not too horrible.

“Anecdata”, Opinions and Reviews

I’m definitely the kind of person that needs to thoroughly research any significant potential purchases before I make them. I have a list of sources I feel I can trust for different kinds of purchases, but I also seek out reviews from complete strangers, often from niche online communities. Although I don’t tend to take any single review as the sole reason why I should or shouldn’t buy something, this kind of anecdata often provides a different kind of information that’s not always evident in a product’s claims.

For example, if I’m looking to buy an ergonomic chair and I read a review that says “I’m a 6’3” man and this chair is absolutely perfect for my size,” this anecdote provides helpful information to me in a way that simply reading the measurements does not.

I shouldn’t need to explain why LLM-generated reviews, testimonials, recipes etc. are worse than useless. The main value from this kind of information comes from the fact that another living, breathing human has tried it. You may not necessarily agree with their take, but a made-up review is essentially garbage that litters the landscape of information.

Fake reviews were already a problem when you needed a human to write them, and now that you’ve cut out another step in the process of generating fake reviews, the problem is worse than ever. A significant amount of time will be spent trying to fight and filter out the bad actors who have no problem with polluting the internet for a quick buck.

Factual Information

I’ve been around long enough to know that the line between ‘objective truth’ and ‘subjective’ is a lot blurrier than some might realize, but for the purposes of this section, I’m calling what is generally agreed upon by the vast majority of people to be ‘factual information.’

Questions like “what time is this flight departing” and “are grapes safe for humans to consume” may differ slightly in terms of how many people can come to an agreement, but there is some general consensus that can be reached.

Sometimes, people just want information presented to them as quickly and as accurately as possible. At first glance, it may seem like LLMs are great for this. We’ve all seen cases where asking a LLM a question returns information that is both accurate and detailed. I have no doubts in my mind that LLMs are capable of providing information that is useful to users, some of the time.

What concerns me the most is when things go wrong. People often understand LLMs to be all-knowing, and it doesn’t help that they are often marketed this way. What some people do not know is that content summarized by AI may contain ‘hallucinations’, AKA factual inaccuracies, dressed up in a cutesy term to make their existence less egregious.

The rate of hallucinations appears to be far higher than some might believe. Vectara, an AI company (take this with a grain of salt!), has created a hallucination evaluation model which aims to test the rate of hallucinations across popular models. To summarize their methodology very briefly, they used different LLMs on their most precise setting to summarize a specific set of documents. The hallucination rates ranged from 3% - 16%, which doesn’t sound too horrible in terms of raw numbers, but should not be an acceptable margin of error on factual information.

Josh Collinsworth sums it up really well in his blog post, I worry our Copilot is leaving some passengers behind.

Why do we accept a product that not only misfires regularly, but sometimes catastrophically?

Let’s say you went out and bought the new, revolutionary vacuum of the future. It’s so amazing, it lets you clean your whole house in half the time! (Or so the vacuum’s marketing department claims, at least.)

Let’s say you got this vacuum home, and sure enough: it’s amazing. It cleans with speed and smarts you’ve never seen before.

But then, you start to realize: a lot of the time, the vacuum isn’t actually doing a very good job.

You realize you spend a lot of time following it around and either redoing what it’s done, or sending it back for another pass.

In fact, sometimes, it even does the exact opposite of what it’s supposed to do, and instead of sucking up dirt and debris, it spews them out across the floor.

You would find that entirely unacceptable. You would take that vacuum back to the store.

If I had a watch that told me the incorrect time 3% of the time, that watch would be useless to me. If I used a travel agent and they gave me incorrect information, resulting in me having to pay more for my flight tickets, I would never use them again. The fact that Air Canada’s AI chatbot has made this very error on their own website and they refused to take responsibility for this mistake is ludicrous.

We as consumers should not accept companies rushing to implement AI chatbots in order to save on labor costs, and we especially should not accept those same companies refusing to take responsibility for the incorrect information that chatbot spews.

While there has been progress in cutting down on hallucinations, the remainder of the work is an uphill battle. You see, LLMs have an element of ‘randomness’ built in. To simplify a complex concept that is better explained by others, LLMs are not deterministic. Putting the same input into an LLM will result in slightly different outputs each time. This is part of the appeal, as it allows people to mass-generate content that is ‘unique’ each time, but results in a non-zero percentage chance for error.

I genuinely fear that one day, someone in a moment of crisis is going to rely on LLM-generated content for a life-or-death question such as ‘how should I help my drunk friend who passed out’ or ‘what should I do when someone is having a seizure’ and get inaccurate results. Even people who would normally think critically about a piece of information may be vulnerable to incorrect information in a moment of crisis. Letting something that cannot be fully verified or controlled run loose to spew misinformation seems counter to our jobs as designers, designing for people.

Interpretive information

LLMs have a really bad time with information that has inpretive intent behind it. For example, blind people rely on alt text, a written description of an image, so that their screen readers can read it out to them in lieu of being able to see the image. Certainly, some alt text is better than no alt text, but AI-generated alt text typically lacks the context behind why an image is included in a site.

For example, take this image from Shutterstock. (I’m linking it so as to avoid paying to include the image on this site, sorry!) The included description for this image is as follows.

Group of Asian people enjoy and fun outdoor lifestyle hiking and camping together on summer travel vacation. Man and woman friends having breakfast drinking brewed coffee near the tent in the morning.

Certainly, this is a valid description for this image. I have no idea if this was human-written or AI-generated, but I would say it is perfectly serviceable for the context of a stock photo website. However, this description does not necessarily represent the reasons why people might include this image in their own content.

• A site selling this particular coffee setup might say: “A group of friends use the portable Coffee Maker 3000 with our kettle in brushed steel in the great outdoors.”
• If this image were posted to social media, it might say: “Me and my best friends John, David and Beth enjoying our coffee while glamping at the local wetland camping reserve.”
• If an extreme anti-camping environmentalist site were to post this image, it might say “Group of people engaging in the environmentally harmful practice of camping on federally-protected nature reserve.”

There are as many ways to describe this image as there are ways to use it in context. Even if AI-generated alt text is accurate, it lacks context. Things like memes and jokes are especially ‘hard’ for LLMs to understand (written with irony here, given that they don’t actually have a consciousness!). To illustrate this point, I asked Copilot to explain the first joke I could find on the /r/Jokes subreddit.

Me: Explain this joke: My teeth were stained, so the dentist asked me, “Do you smoke or drink coffee?” I told him I drink it.

Copilot: Okay, I can try to explain the joke to you. The joke is based on the ambiguity of the word “it” in the sentence “I drink it”. The dentist is asking the person if they smoke or drink coffee, because both of these habits can stain the teeth. The person replies that they drink it, which could mean either coffee or smoke. The joke is that the person is implying that they drink smoke, which is absurd and nonsensical. The joke is meant to be funny because of the unexpected and ridiculous answer. I hope this helps you understand the joke better.

Copilot’s explanation is partially correct. It correctly states that the joke is based on the dentist’s wording being ambiguously interpreted as either smoking or drinking coffee. However, it misses the mark in saying the person is implying they drink smoke.

I hope the joke example clarifies why interpretation is so important when it comes to understanding information. Sadly, I know there are entire masses of people out there who are excited to give even less of a shit about disabled people than they already do. They are excited to automate this alt text problem away so they don’t have to spend a single second thinking about what they as a sighted user do not benefit from. They don’t realize that crafting alt text is an art, I’m not ready to hand over art to the robots just yet.

Educational content

There’s a type of content that I’m having a hard time describing in a short phrase. Essentially, by ‘educational content’, I’m referring to content that does have factual elements, but the primary value of the content is that it’s presented in a way that really enhances a reader’s understanding of the material. It’s not necessarily content that comes from educational instutions. The author may have put their own spin or understanding on it in a way that reading a summary of the information misses out on a lot of the value it brings.

I consider Ahmad Shadeed’s piece on Designing better target sizes to be an absolute masterpiece in this genre. The article is chocked full of interactive examples, techniques and caveats that is helpful to a wide audience, regardless of background. The language is simple enough for a reader with no prior knowledge to understand, but the information is detailed enough that experienced readers can pick up a new insight or two. It’s what I aspire to with my technical writing.

As someone who’s dabbled in writing educational content, it’s not easy to create content like this, with good articles taking days, weeks or even months to finish. The thing is, it’s already really difficult to find people willing to pay for this content. Inside the tech bubble I work in, with the exclusion of paid software, there’s often not enough money going around to pay technical writers. Although technical writers must be both technical enough to understand the subject matter on a deep level, and good enough of a writer to be able to communicate that knoweldge, it’s simply really hard to get the same rates you would for writing about code as you would for writing actual code.

From what I’ve seen, LLMs aren’t good enough to create something as helpful as a good piece of human-authored technical writing, period. Try as I might, I could not get Copilot to output something about target sizes that even came anywhere close to the article written by Ahmad. The problem is that people believe that it can, thus shrinking the already tiny pool of jobs for good technical writers. Even MDN, a resource that I’d wager every single web developer has looked at at one point, felt that AI was worth implementing on their docs, though it was met with much public outcry. In an age where documentation is being replaced with discord servers, it feels like the trajectory of software development is moving towards reviewing the code output of AI, and when the aforementioned code doesn’t run, ask the AI chatbot for help. Pretty bleak.

Conclusion

Unfortunately, the cat (or the Bullshit Generator) is already out of the bag on this one. We can’t really take it back at this point, and the message from the technocrats is clear, adopt or fall behind. The personal impact of failing to adapt can be devastating when your entire livelihood depends on meeting a certain level of producitvity. My only bit of advice is to push back in your own way. Whether it be fighting unethical use of AI at your workplace, occasionally writing a blog post, curating a list of human-authored content, or logging off, my hope is that we all do what we can to stem the rising tide.

Related Reading

• The exact scope and scale of the problem is difficult to determine, but if these Amazon listings are anything to go by, we are in a world of trouble.
• Josh Dzieza dives into the world of AI-generated fiction
• AI isn’t explicitly mentioned in this piece entitled ‘How Google is killing independent sites like ours’, but if the quality of the content doesn’t matter, it’s only a matter of time
• Headnodding along to this piece by Nicolas Magand
• This mastodon post by Heather Buchel is short, but apt.
• Dave Rupert has A dozen short thoughts about AI
• I actually came across this post by Joe Dolson about AI-generated alt text after I wrote the section on it, it adds a lot of valuable Wordpress development context.
• Andy Bell digs into the problem of MDN
• Robert Kingett shares his opinion on the usefulness of AI for the blind community

Related Reading

This was a short piece on a huge topic. Here are some recent posts I enjoyed that touched on similar issues.

• Jim Nielsen laments how buying one thing now opts you into a lifetime of unwanted emails, unless you opt out
• Todd Libby, web developer and accessibility engineer, on his decision to leave tech
• Dave Rupert on the what a website can do
• Blake Watson on building your own things
• Jason Velazquez writes beautifully on where all the websites have gone
• Craig Abbott sums up why we’ve gotten ourselves into this position from an accessibility perspective

Thank you to my friend Becky for her thoughts on an initial draft of this piece.

Responses

• Hidde de Vries outlines specific ethical things we can be aware of in this banger of an old post
• Jeremy Keith shares an anecdote and a talk recommendation I’ll be looking out for

The Problem

I know this can be hard to see at full speed, so I’ve quickly thrown together a little interface below so you can adjust the playback speed in browsers/feed readers that don’t show a playback speed toggle by default. It’s probably a little janky, and may not work in RSS feeds. My apologies.

Unsure of whether or not this was just my implementation, I tried to track down other examples in which this issue occurs. I was able to reproduce this in Astro’s demo for View Transitions as well. Given that Astro got a nice little shoutout on the Chrome Developer blog, I presume it meant someone from Chrome did take a look at the implementation at one point, so seemed to point something to do with the browser rather than developer error.

If you couldn’t spot the problem, here’s a static screenshot of the demo at the exact point of failure as well:

I sent out a few feelers in the ever-helpful Shoptalk Show Discord and tried various things with no success, such as adjusting the z-index, transform and will-change properties on the animating elements, but without any success whatsoever. I ended up filing a bug report for Chromium, where the I was directed to this Github issue with a detailed explanation from Khushal Sagar, a Chromium engineer, which is worth checking out.

The Workaround

Basically, here’s my understanding of the issue, from a non-browser developer perspective. View transitions aren’t actually moving your elements around in the DOM, the browser is doing secret work to take a snapshot of what the elements would look like as a flat raster image, and doing Animorphs Magic (Thanks Dave!) to morph between these images.

Paint order, the order in which your elements are painted, cannot be easily calculated without applying a complex algorithm, especially since many uses of View Transitions involve transitioning between pages. There isn’t really a way to figure out the shared stacking context between two pages, because if we had to consider the z-index of every page simultaneously to account for every possible transition, our heads/computers might explode. The compromise that exists is that the browser tries to paint the elements in the following order (paraphrased from Khushal):

1. Paint all the view-transition-names in the old DOM, while respecting the existing order of these elements
2. Paint all the view-transition-names that exist only/are visible in the new DOM, while respecting the existing order of these elements. This goes on top of all the other things above.

You will note here that elements without a view-transition-name are not included in this paint order. I didn’t have a transition name on my footer, as I had only worked on a single page, and footer had no animation at all. So, in order for my footer to be included in this paint order within this animation, I just had to stick a view-transition-name property onto the footer, even though it’s not actually being transitioned.

If your use-case is slightly different and you are transitioning between elements that don’t exist, whether it be due to an element being hidden with display: none or transitioning between pages with unique elements such as in the Astro demo, you will want to make sure that:

1. Your problematic sticky element has a view-transition-name property on it.
2. You are rearranging the order of the painted element with z-index, to make sure it appears on top of all your other animated groups.

This results in code that looks like this:

.myFixedFooter {
	position: fixed;
	view-transition-name: footer;
}

::view-transition-group(footer) {
	z-index: 100;
}

Initially, I was confused as to why things weren’t working in the way that I expected. It felt not intuitive to apply a transition name to something I wasn’t transitioning, and I wasn’t sure why my z-index outside of the transition had no effect on the transition!

However, after reading through the explanation and finding the workaround, I’m personally okay with this limitation for my use case. Z-index + transitions has always been slightly iffy, and in this case, I’m just really glad there’s a workaround.

Day 3

Feeling ambitious, I write a Svelte store that allows me to manage the minimized/maximized state of all the windows. Unfortunately, I notice that the order in which the window ‘registration’ occurs is random, and I’d like it to reflect the order on the page, so I spend some time trying to coax it into order while cursing my existence. I end up with a workable solution that doesn’t take too long, as I’m personally ok if the window list at the bottom of the page comes in after JavaScript renders as it’s mainly for ‘flavor’. If it was a part of the main content, I probably wouldn’t accept this tradeoff.

Deciding that I’m done with JavaScript for the day, I move on to some of the design aspects. I first establish the kind of button style I want for the UI buttons, which requires attempting to rewrite the pixel-borders mixin. I successfully refactor the mixin to use relative units, so that it scales nicely with the rest of my UI, but I cannot get it to take my CSS variables as a color input. This is because the mixin uses SVGs within a CSS url attribute, and these are treated as as external documents. I experiment with using mask borders instead of border images, but the browser support is pretty bad. Defeated, I accept that my design system will no longer be ‘perfect’, and accept that I have to pass in a hex code for my borders.

I throw together a list of client logos and hope no one gets too mad at me for ruining their brand. I’m going for the crunchy 88*31 blinkie look, though I decide to increase the size for legibility. Think geocities, but purple.

I hastily scribble together a close icon (a little ‘x’) to see what it looks like in context. I fall down a bit of a rabbit hole, making many different versions of the icons across different sizes and resolutions. My normal SVG workflow is to run them through SVGOMG, but this has a disastrous effect on the pixel art style. The default export from the spriting program I’m using draws individual rect elements for every pixel. As you can imagine, this doesn’t generate the smallest file size, but preserves the pixel art as one would expect. SVGOMG converts the rects within the svgs into a path, which smooths the whole thing out. While this behavior is normally desirable, this is exactly what I don’t want for this project.

Through my experimentation, I discover the image-rendering: pixelated property does exactly what I want it to as well! I now have a suitable method for rendering both SVG icons and raster images! I can pick and choose based on the file size, since the SVG exports won’t be as tiny as they normally are. Chuffed with my progress, I leave it here for today.

Day 4

Day 3 and day 4 happen with a huge gap between them. This is because I feel the need to flesh out the illustration work a lot more before moving forward. I’ve been working on a client project where illustrations were involved, and it was difficult to progress with the final design work until the illustration style was fully locked in.

In my case, this meant working on at least one of the ‘desktop icons’ as well as the background. This may lead you to think I spent a whole bunch of time painstakingly crafting the illustrations, but actually I just procrastinated until I felt too much guilt and finally opened up Aseprite, the new pixel art editor I bought just to make these illustrations. Sometimes, I find myself needing to invest in something that will help me get stuff done as a motivational tool.

I’m not entirely happy with either the background illustration or the icon, but now that I have a sense of direction, it helps me out quite a bit. I adjust some colors to make sure they meet contrast requirements, something that was hard to do without having a background in place. Right now, I’m dumping all my images in the repository instead of Cloudinary, because I can’t make any decisions. Much to my chagrin and embarrassment, I’m up to 8 versions of the close button alone, and 5 versions of the background. I hate to say it, but I’m up there with the most indecisive of clients.

The particularly observant of you may note that although I have 8 versions of the close button, but don’t have any close buttons at all in the screenshot above. Fear not, they will return again, on another page! I think it doesn’t make sense to have the windows be closeable on the homepage, so yeah.

I did a lot of work developing the window component and how to make it usable for various different contexts, like what happens if there’s just one content window vs. many, how they stack on top of each other and etc. This didn’t result in a lot of ‘visible’ changes, but it helped me feel more confident in the overall direction of the project. If I know the fundamentals work, I hopefully won’t reach a scenario where the entire UI idea falls apart. Hopefully.

I spent a long time playing around with the new View Transition API to animate how the windows would maximize and minimize. For the most part, it looks really slick when it comes to moving things around, even with the defaults. The one animation I don’t like is the maximizing window option. I was expecting the text to reflow like how the browser does it, but since learning that the API basically transitions static images, it meant the text scaled up statically, then janked back into place, and there would be no way around this.. I opted for the default cross-fade animation for maximizing instead. I know there are ways to make this work with animation libraries, but I didn’t want that kind of overhead.

Writing that last paragraph sent into a small existential crisis as I contemplated if Svelte was the right technology to use. I like Svelte and enjoy building with it, but I wonder if I would have been better served by making the Window svelte component a web component. Putting your money where your mouth is, as one might say. The premise seems simple, but I don’t feel too optimistic, as there is quite a bit of state that needs to be managed externally (ie. the footer windows), and I do need to reach out of the component to calculate some sizing and positioning attributes. I tell myself it was the right decision to build it as a Svelte component, and cry myself to sleep.

Read part three

Non-development work

I am not a designer, and I have limited ability to use any design software to produce designs. When I am in a position where I do have to design, I tend to come up with stuff more iteratively. I typically tend to only nail down the broader stroke stuff first like colors and type, then I refine as I go on. I looked at pixel style video games, ‘vaporwave’ UI designs and the good ol’ Windows 95 UI to in order to get a sense of overall design language.

Because I liked my current site colors, I grabbed all my primary brand colors and shoved them into this color scale generator. I tinkered with it to make 2 lighter and darker tints/shades for each primary color I had, then I plugged everything into my all-time favorite, Are My Colors Accessible to make this monster color chart that I could reference to find accessible color combinations.

I did a few font tryouts but settled on W95FA as my main font. I liked how legible it is compared to other pixel fonts, but I also knew that I probably needed to make a toggle to allow for a high-res font in case anyone struggles with reading it. After perusing Modern Font Stacks, I settled on the ‘Humanist’ font stack as a nice fallback font stack.

I consulted the hivemind over in the Array Discord on sites with great about/services page, since that was an area of my site I felt was particularly lacking. Special shoutout to Steven Woodson who gave me a list of references he consulted when he went through the process of rebranding recently. Having some sense of what the copy on each page looked like made it much easier to wireframe, I’m very much a fan of designing the site to fit the content you have and not the other way around. I ended up scribbling some very loose wireframes with good ol’ pen and paper.

Finally, onto the actual development!

Day 1: Panic, in my office

• Decided to stream for my mentees
• I had been struggling to choose between using 11ty (what my site uses currently) and Astro (a tool I’d like to play around more with. I decide on Astro as I think this iteration of the portfolio will be a little more JS heavy and I wanted to use Svelte for the component-y bits.
• Grace showed up to watch me stream! I panicked as I soon realized that I cannot talk and problem solve at the same time. I tried to get around this by only coding the most absolute basic markup elements while discussing CSS with Grace.
• I contemplated using SCSS or not, but ultimately decided on including it, because the Dark mode toggle pattern I use 1. relies heavily on CSS Variables 2. respects the OS preference for the color scheme but allows for overriding it via a control on the website. I do NOT want to have to copy and paste the variables in two places, as I know this will only bring me pain. For this alone, I decide it’s worth it to include SCSS.

@mixin dark-colors {
	// all my variables here
}
@media (prefers-color-scheme: dark) {
	:root:not([data-user-color-scheme]) {
		@include dark-colors;
	}
}
[data-user-color-scheme="dark"] {
	@include dark-colors;
}

• My dear friend EJ Mason came to my rescue and helped me answer some tough questions about CSS architecture. We vent about comboboxes. Grace listens to us very patiently.
• We soon realized that with this current design, when you are on the home page there are actually 3 links that point to ‘Home’. I contemplate making the bottom left ‘Home’ button say ‘Start’, but EJ correctly points out this is a WCAG violation. For now, I make the second ‘Home’ in the bottom bar just text, and decide to solve this later.
• Copilot offers me a suggestion to generate the JS and markup for the Minimize, Maximize and Close buttons. I accept this suggestion to save myself the pain of typing it out. EJ and I realize that while the JS for the buttons is functionally correct, the HTML for the buttons is all unlabelled divs. We lament the state of AI in modern web development.
• I decide to incorporate this pixel borders SCSS mixin as it looks awesome and justifies my use of SCSS, but realize it only uses pixels instead of rems and does not take CSS variables. I don’t think the use of pixels is ultimately terrible as the borders not resizing with font sizes isn’t the end of the world, but I would like to see if I can rewrite it better for my own modern workflow later. I include it as a utility class for now with the intention of rewriting it.

Day 2: Looking at the View Transitions API

• I promised all my friends banana bread today but realized I actually tossed my banana bread pan, so I need to go buy a new one. Unfortunately, the kitchen supplies store was closed so I had a few weekend hours to kill. Back to the website it is!
• I wanted to make it so that when only the screen is large enough (to account for high zoom levels), the footer and sidebar icons remain sticky, and the content of my little window panes scroll within the allocated space remaining. However, CSS Grid is NOT cooperating with me and despite setting max-height: 100dvh on my grid container, the main content grid item decides to bust out of it. I spend an hour or two pouring through stack overflow until I found this answer, which informed me that grid items have an implicit min-height: auto on it. I set min-height: 0 on the main window pane area and the layout snapped into place as it should. Who knew!
• I contemplated stuffing each page’s content into one giant window vs. creating little windows, and even contemplated the dreaded possibility of having different windows for small screens and large screens. Decided that multiple little windows make for good sectioning elements and that it would be fun to fill the horizontal space on larger screens. I made a note to write the rest of my homepage copy with urgency.
• Came up with a little way to pass in different positioning props into the windows so I could arrange them nicely on desktop for each page. I get the window ‘maximize’ functionality working without a hitch.
• I thought the default View Transitions way of cross fade-ing the windows looked pretty cool. Tried to come up with a better custom transition that scales the window size, but ultimately returned to the cross fade for now as I noticed that the text size scales up with the animation in a weird way.
• I realized that I have inadvertently solved the start bar ‘Home’ design problem by breaking up each pages content into multiple windows as I can just have the list of windows titles, but this creates a lot of extra work if I want to support ‘minimizing’ a window. I wanted this to be possible as the original plan was to create some absolutely gorgeous pixel artwork for the background that hopefully people wanted to look at. Implementing this as planned meant creating some kind of global window store object that tracks the state of each window. I also agonized over ‘Close’ button, which I was going to treat as a ‘back button’, where closing the window would return to either the Home page or the parent page (ie. all blog posts if you are on a blog page, etc.) I then wondered if that’s going to be confusing UX, and realized I had no idea what to do with the ‘Close’ buttons on the homepage. Finally, in classic anxious form, I contemplated omitting this section completely as it was likely to be too confusing to read, but settled keeping it as sometimes Web Sites Are Pain and this log should reflect that.
• Wanted to create a live link somewhere to gather some inital feedback, but realized I broke the default Astro blog template somewhere along the way.
• I decide all of this is just way too much for a Saturday morning and notice that the kitchen goods supplies store is now open, time to make banana bread!

Read part two

Introduction (0:00)

Hi, everyone, my name is Nic Chan and today I’ll be speaking to you on “Developing an Accessible ‘Add to Cart’ Flow.” If you have any questions or comments, you can find me on my website at www.nicchan.me. That’s spelt N-I-C, C-H-A-N, or on my Twitter handle, @NicMakesStuff. I’m a Hong Kong woman with wavy black hair, and I’m wearing a purple an Axe-con shirt much like Liz. To give you a brief introduction, I’m a freelance front-end developer. And the insights from this talk are sort of gleaned from my years of experience working on Shopify stores. But hopefully the insights can also be applied to other e-commerce platforms. And fun fact, I’m definitely a cat person.

Overview (0:53)

To give you a sense of how this talk is gonna go, today, I’ll be covering four different patterns, first being buttons, then inline notifications, then toasts, and then dialogs. And for each pattern, I’m gonna walk you through some different iterations, so some different variations of what these patterns might look like in the wild. And then pros and cons for each pattern, as well as tips and tricks for implementing them in a more accessible way.

So to make sure we’re all on the same page, here’s a typical Product page. I’m sure many of you have seen some variation of this in the wild before. On top, we have our breadcrumbs, which is our links that point to different parts of the website. Underneath that we have our slide images, and some thumbnail images. On the right, we have a product title and a product price, we have some variants for selecting a different color. And below that we have our star of today’s show, it’s the Add to Cart button. Underneath that we have a product description. There’s lots of things to comment on this with regards to accessibility but for now, we’re just gonna be focusing on what happens after that Add to Cart button.

So the first thing we wanna do is make sure that we’re always using a form element. The reason why we would wanna do this is for two main reasons: progressive enhancement and semantics. There’s this common misconception that screen reader users can’t use JavaScript, but that’s just a myth, it’s not really relevant. The main reasons are for progressive enhancement and semantics. Progressive enhancement being the idea that we want our site to work for as many users as possible. So if for some reason the JavaScript fails, we’d still want our key actions to be able to be performed by our user and that includes our Add to Cart. In terms of semantics, assistive technologies offer the functionality to jump to things like different elements on the page, including form elements.

So by including a proper form element here, we can provide users that functionality. It’s much like a table of contents in a book. So if someone wanted to skip to a particular point, they can just browse that table of contents, and then jump to what they need instead of just having to listen to the entire page before reaching that form. So what happens with this default form example? Well, we can see that the form element has an action attribute on it, which points to a /cart/add route.And when you hit that Submit button, it’ll take you to that /add route and it’ll add that item to your cart and then presumably, it’s gonna redirect you to a cart page. This solves a whole bunch of accessibility issues for us. Because navigating to a new page is a fundamental interaction of the web, almost all assistive technologies support that and your users understand that, okay, like we’re on a new page, it’s titled your cart, and I can see that the item is now in my cart, and I understand what has just happened here.

So if this approach is so robust, why would we ever wanna use an alternative? Merchants realized that this was kind of like pushing users into a single flow, it’s forcing them to Checkout when they might not wanna always go to checkout, they might wanna continue shopping on the site or do some other action first. So the following patterns are kind of developed as a way to both notify users and offer them a choice of whether or not to continue shopping or proceed to checkout. Now that we’re all on the same page, let’s move into the actual patterns.

Button Pattern (5:02)

The first pattern is a button pattern. And here I have an image. And on top, we have our first button, and it just says Add to Cart. Underneath that we have a second button, and there’s a checkmark in it, and it says Added to Cart instead of Add to Cart. When I refer to the button pattern, I’m referring to when the buttons text is changed when it is activated. This is a pattern that can be used in combination with other patterns, and I’d recommend it for the following reasons, and that is super great for users who use magnification, whether it be the default browser zoom, or special zooming software.

So here I have a screenshot of a user who is using ZoomText to browse our page. And on this, they can only see a small region of the page, they can only see that price, and then the color variant, our Add to Cart button, and then one or two lines of description, so they only see a pretty small region. It’s really good to have an indication of the state of the page in the place that they’re currently looking at. So if we use the button pattern it might look something like this.

And here we can see that very same region of the page and our Add to Cart button now says ‘Adding’. So moving on to implementation details. This type of pattern is typically implemented by using JavaScript to change the text.

So here we have, and we have our form element. And then below that we have some JavaScript where we’re just adding the item to the cart, and then we’re changing the inner text of that button to say ‘Adding’. In isolation, this isn’t a recommended approach because screen reader users aren’t that great at handling text changes consistently. So while some screen readers may support changing the inner text of a button that’s focused, a lot of screen readers don’t. So we can consider using live regions in order to provide better support for screen reader users. If the button is your only indication of state, you definitely want to be using live regions.

Live regions are a way to announce changes in your site to assistive technology users. You can kind of think of them as a web equivalent of the inflight announcement on a plane, like you’re just watching a movie, you’re having a good time, and then suddenly, the captain’s voice just interrupts and tells you that you’re about to land. That’s kind of like what a live region is. There are only for text only announcements, you can’t really do anything with them. Live regions can be created by adding the aria-live attribute with a value of either polite or assertive. By using polite, you’re telling the assistive technology for the current text to be finished before announcing what is in the live region whereas if you use assertive, it’ll just interrupt the user, no matter what they’re listening to. Live regions work most consistently when they’re already present in the DOM. You don’t wanna be adding them dynamically using JavaScript, you typically wanna have a live region already on your page, and then use JavaScript to add or remove text to it whenever relevant.

So here we have our code sample. And we have our form element. And below that we already have a live region with the attribute aria-live=“polite.” And below that we have our JavaScript. When we add the item to the cart, we’re grabbing that live region and we’re grabbing that button. And we’re changing the text of both of these elements to be the same thing. Sometimes developers might wanna disable that Add to Cart button while the action is being assessed in order to prevent double submission. So sometimes users accidentally click it, click the Add to Cart button twice, and then you have two items in your cart instead of one. And developers often use the disabled attribute to kind of prevent this. Using disabled isn’t always the best choice because if you’re not managing the focus correctly after, you can cause the user to lose focus, and then lose keyboard focus.

So an alternative might be to use the aria-disabled=“true” attribute instead, and use some additional code and styling to make sure that the same functionality is provided. But using aria-disabled might really not be any better because what can be announced to screen reader users can sometimes be confusing. For example, a screen reader might say something like Add to Cart unavailable. And that’s especially confusing in an e-commerce context because, you know, how will the user know if the button is unavailable, or the product that they’re trying to buy is unavailable.

So in this case, you would really wanna consider your user base. If your website is selling to a technical audience, maybe your audience will have a higher level of technical proficiency and they’ll understand that this is actually unavailable as being applied to the button and not the product, and it will be okay. But you’d really wanna consider testing with users whether or not the disabled attribute is even needed or if you should just disable the click with JavaScript.

One final consideration for the Add to Cart button is wording. So here we have a diagram of two different possible wording flows. On the left, we have a button that says Add to Cart, and then it says Adding, and then it reverts back to Add to Cart. This can be confusing if it’s the only indication of state because it requires users to be very actively paying attention to what might be a small difference. You’d have to imagine your user just staring at that region of the screen. And if your website loads fast as hopefully it should do, it’s gonna revert very quickly back to the original Add to Cart state. And if that’s your only indication, it’s not too clear that anything has happened.

On the right, we have a button that says Add to Cart and then Adding and then the final state is Added to Cart. This poses a different problem of if you want to reset that button to the original state. There tends to be room for confusion about now, it’s pretty clear that an Add to Cart button allows you to add something to your cart but what does an Added to Cart button do? Does it take you to Checkout? Does it let you add that item again? It’s a mystery. So we might wanna consider using the button pattern in combination with other patterns in order to alleviate some confusion. And this leads us to our next pattern.

Inline notifications (12:34)

What do I mean when I refer to the inline notification pattern? By inline notification, I mean an element that is not positioned sticky, absolute or fixed. A notification is inserted into the reading area and then content is often shifted in order to make space for this notification.

So here we have an image. It’s our same Product page as before and this time, underneath the Add to Cart button, we have a notification that lets us know that our product has been added to the cart. So we’ve already discussed the idea of using live regions as a way of presenting content to assistive technologies, should we be using them here? Live regions can best be thought of as temporary notifications.They’re the web equivalent of an announcement blaring at you over the loudspeaker. If you’re not in a logical place, like how I’ve placed it right under the Add to Cart button here, it might not be obvious where in the DOM they are, and a screen reader user has no option to go back and listen to that text again. Furthermore, zoom magnification users who don’t use accompanying audio could be left out and they could miss this notification entirely.

A better approach would be to programmatically move the focus to the notification once it enters the DOM. And then this will be announced to screen reader users and other groups. So here we have our code samples. And we have a notification that has a tabindex of negative one,which lets the browser know that this element will be programmatically focused, but not included in the default focus order. And below that, we have our JavaScript and we’re once again we’re just adding that item to the cart and then we are grabbing our notification, the text of that notification to what we want it to be and then we’re moving focus.

Sometimes our notification isn’t just text, but it also includes interactive elements. So here we have the same image as before with our Add to Cart button and then below that is our notification. This time, I’ve added two links to this notification. So underneath that notification text, there’s a link that says Continue Shopping. In these situations, we have to move focus, because our aria-live regions strip semantics of child elements. So a screen reader user might be able to tell that these are actions from the words, but they’re gonna hear the words Continue Shopping or View Cart that has interacting with them.

Some implementations will have this notification disappear after a short amount of time. While this is not advisable due to being easily missable, it’s also a WCAG failure of the 2.2.1 Timing Adjustable Criteria. Essentially, this criterion exists to make sure that we’re allowing people to have adequate time to complete interactions. Because we’re providing different interactions within the notification, hiding the notification automatically can prevent users from completing them. So a better way around this would be to add a button to dismiss the notification manually instead.

In the wild, I often see different placement options for this pattern. So here we have two examples of where we might put our notifications. And the first one is directly below our breadcrumbs, but above all of our product stuff. And the second one is in a similar location to the original notification, but it’s directly above the Add to Cart button. I’d argue that the best place for the notification is after the Add to Cart button. Well, if we’re moving focus, technically, we meet the requirements either way, but we can improve usability by not taking users too far out of the context they were originally in. Placing it near the button helps minimize tab stops for keyboard users and it will disorient users with dramatic content shifts if you’re kind of like shifting things around the page. If we put it under the button that they’re probably looking at, we have less room for disorientation.

Inline notifications (17:17)

The next two patterns I will be discussing are toasts and Dialogs. Before I get into the details, I’d like to emphasize that these patterns often lack distinctions in the wild. I’ll be describing the behaviors of both toasts and Dialogs in terms of how they should be behaved, but the lines are really blurred. Because they pop out on the screen and overlay content, people kind of just tend to see a toast as a little dialog, and they code them in a really similar way. This ignores distinctions and semantics and the requirements for each of these elements to be accessible. A lot of accessibility errors come about from developers treating these two components as interchangeable when they’re actually quite discreet.

So what is a toast? A toast is named after the behavior of a toaster.It’s an element that kind of pops up in a fixed position on the screen, typically in the top right, bottom right,underneath the nav bar, and other places like that. And they should have a role=“status” or role=“alert” attribute on them, or an aria-live attribute so that they’re announced to assistive technology users. Focus typically isn’t moved to a toast. Contrary to how toasters work in real life, toasts on the web often disappear after a few seconds.

Should we be using toasts in an e-commerce context? A lot of the problems with toast stem from the fact that by definition, focus, isn’t moved to it. Furthermore, toast inherently have a problem shared with a lot of fixed position elements, they’re really easily missable by zoom users. You can imagine that if we’re zoomed into that Add to Cart button and something pops up in the top right of the page, it’s not that useful for a user who’s just looking at that Add to Cart button region. Here we have a visual and we have a example of a toast.

Our toast looks really similar to the inline notification that we have previously but it’s overlaying our content and it lives on the top right of our page, and it disappears after a few seconds. Early on, we discussed the 2.2.1 Timing Adjustable Criteria and the problem with child elements and this applies very much to this example right here. Trying to interact with a notification that disappears is about as frustrating as your toast vanishing off your plate while you try to eat it. Not recommended.

So how do we make sure that we don’t fail the 2.2.1 Timing Adjustable Criterion while keeping tools behavior? We have some options. The first is that we could have a setting that lets you set that notification display time. And here we have an example of a settings page where we just allow the user to set the notification to five seconds. On the right, we have an example of a notification drawer and it looks a lot like a notification jar on your phone. Basically, it shows you all the toasts that have popped up previously with a timestamp of how recently they popped up. Sure, we can use both of these options to kind of remediate the issues with toasts, but it sort of defeats the purpose of toasts as a quick and easy way of displaying things. Plus no one really wants a drawer full of stale toasts. Unfortunately, I don’t really think that toasts live up to their real life namesake. They’re neither as useful nor as delicious as their real world counterparts, especially in e-commerce contexts where the Add to Cart is the primary action. What developers often try to implement as toasts should really be dialogs instead. And this leads us to our final section.

Dialogs (21:18)

Dialogs. Dialogs are often a misunderstood component, there is a misconception that all dialogs are basically what we understand to be an alert. Here on the screen, I have an example of a Windows 98 Style dialog. And it basically says “The system registry has been backed up already today. Would you like to back it up again?” And it provides option of Yes or No. All of the following patterns are examples of things I regularly see on online stores. While visually they look really different, they can all be considered dialogs. And so they can use similar semantics and functionality underneath the visual styling.

This is a dialog. So what we have here is a Product page that we had before and we have something that looks really similar to our toast example. It has “Your product has been Added to Cart” text, and it has our to Continue Shopping or View Cart links. And the only difference is that we’ve now added a little Close button in the top right so a user can dismiss it.

This is also a dialog. So here we have a Products page and there’s a white semi-transparent overlay on top of that page. And on top of that, we have a kind of more expanded dialog. And we have our “Product has been Added to Cart” text, we have an image of product and then below that, we have our Continue Shopping and View Cart links styled more prominently. And there’s also a Close button here.

This is also a dialog. So here we have a Product page and the difference is now we have a navigation bar and in the top right we have a button that will trigger the cart, and below that, we have our dialog and it has a title of your cart and within it, it has all the products that are in our cart, the total price, and then the option to Checkout.

This is also a dialog. So here we have our Product page, we have our semi-transparent overlay overlaying the content. And on the right hand side of the page, we kind of have like a cart and floor type situation that slides out from the right. And we have a title of your cart, all our products, the price and the Checkout button. The primary difference between these dialogs is whether or not they’re modal or non-modal.

Non-modal dialogs don’t prevent interactions between the rest of the webpage when they’re open, but modal dialogs do. So if you have a backdrop behind your dialog, that probably would suggest that it is modal and your dialog should be coded in a modal way.

Now that we know that all these seemingly different patterns are actually just dialogs under the hood, I’m gonna give you some advice on implementation details.

It’s my opinion that if web development were a video game, hand rolling your own dialog would be the final boss. I’m not gonna go into all the intricacies of building an accessible dialog because it is super complex, but here are a few tricks that can help you when evaluating dialogs on your site and perhaps letting you know if your current solution is okay or if you need to find something else.

Focus management. So regardless of whether or not your dialog is modal or non-modal, we wanna be moving focus to the dialog. If your dialog is modal, you also want to trap focus, which means that you shouldn’t be able to move focus to the document that’s in the background. When the dialog is open, hitting Tab a whole bunch of times suggests cycle between the elements within the modal and then shift to the browser UI. This browser UI is often forgotten part of the focus trapping.

When we close the dialog, we should return the focus to the element that opened the dialog. In this case, it’s our friend the Add to Cart button. But if you’ve opted for a mini cart, or some other kind of cart thing that can be opened through another part of the page, you’ll probably wanna account for handling different mobile triggers and moving focus to the correct element that opened the modal in that scenario.

Keyboard. We don’t wanna forget our keyboard shortcuts. When you hit the Escape key, the dialog should close. If the dialog is modal, we wanna make sure that assistive technology users can’t escape from the modal via other means. So oftentimes, I find developers will correctly implement focus trapping, which traps focus within the dialog but you also need to make sure that the document behind the modal is hidden from users when the modal is open. You can consider using the aria-modal=“true” attribute in the future but the browser support is not that great right now. So in the meantime, you can probably consider using the inert attribute with a polyfill in order to make sure that the rest of the document is correctly hidden from assistive technology users.

And finally, we don’t wanna dismiss the dialog automatically.Well, the dialog element is just about here. I have to give a shout out to Safari,which just dropped an update, 15.4, like two days ago, which caused me to frantically update these slides. The dialog element is so close, it’s a great time to begin experimenting with deploying it in the future, but if you’re a developer who needs to support older browsers, you might still wanna wait and you can continue using a with a role=“dialog” until the browser support is just a little bit better.

Finally we wanna make sure that we’re labeling all the things. We wanna make sure we’re labeling the dialog itself. Consider using a aria-labelledby attribute, which will point to the ID of the element that labels the dialog. So it might be the text of the dialog or it’s a heading like your shopping cart, we just wanna make sure that our dialog is labeled.

It’s a really common issue that’s found in modal carts and things like that so if your dialog has repetitive interactive elements, so like multiple Increase Quantity buttons, or multiple Remove Product buttons, one for each of your products, make sure that they have unique names. It can be annoying for a screen reader user to just list all the buttons, and hear five different buttons that say Remove with no indication of what product they’re actually removing. So we wanna make sure that each of these buttons are labeled with a unique name.

Inline notifications (29:05)

Some final takeaways. I don’t think there’s a clear winner amongst the pattern. How you might use them really depends on the context of your site. Things like how many products you have, or what you want a user to do after adding an item to the cart, it sort of really drives which one of these patterns you’ll wanna use.

And while testing individual components is great, we really wanna test the whole flow. So you can see that when we combine the patterns in different ways, different considerations pop up. So it’s really necessary to not just individual components in our design system, but to test the entire flow to make sure that once you put it all together, it works in an accessible way. Finally, toasts and dialogs are not the same.

A whole bunch of accessibility errors come about from treating different components interchangeably. If you only learn one thing from this talk, let it be that toasts and dialogs are not the same. And with that, I’m pretty much done. So I guess I’ll hand it back to you Liz for questions.

Questions & Answers (30:14)

Liz: Awesome. Thank you so much Nic for a great presentation here. And thank you for adding questions for all of our attendees. Please still feel free to add any questions that you have for Nic in the Q&A portion. And definitely Feel free to upload them and I’ll make sure to go with the ones that have the most votes. So let’s dive into the first question. This one’s on toasts. Should toasts be used for simple success confirmation messages that would have no interactions with it, such as Saved Successfully, Copy to Clipboard, et cetera?

Nic: Yeah, I think if there’s any place for toasts, it would be on those simple confirmation messages, as you’ve just said, especially if a user is gonna be triggering that action several times in a session. Like, if you are, you know, working in Google Docs or working in an art program, you wanna make sure your stuff is saved, and you probably save like 500 times an hour like I do, so in that case, so toast is probably appropriate.

Liz: Definitely. Okay, awesome. Next question here. Okay, this is on Add to Cart button. So could we use the Add to Cart button as a live region, instead of creating a live region and a separate div element?

Nic: I think that would conflict. I think it would cause a conflict because live regions, they will strip semantics from things. So because the button is a semantic element, we probably shouldn’t use a live region on it. I’m sure reading the spec of what it’s appropriate to add aria-live to will reveal whether or not it’s an actual spec incompatibility, or if it’s just something that we probably shouldn’t do, but I probably wouldn’t do it.

Liz: Okay. Great. Thank you, Nic. All right, got some more questions coming on here. Okay, what tools would you recommend someone use who is new to accessibility?

Nic: There are so many different tools for different things, I can’t really think of any e-commerce ones off the top of my head. I have written an article for Smashing Magazine that is just entirely a ginormous list of different accessibility tools, and they’re categorized by different uses. So for example, there’s like tools for reading level, which can help with cognitive accessibility, or tools for color so you might wanna check that out.

Liz: Awesome. Thank you. Okay, another one on toast messages. Should toast messages be removed automatically after a set time, or both hide and remove it?

Nic: So if you add a button to a toast, it kind of becomes a dialog. And that’s part of where the issue is. Toast by definition should be removed after a set period of time, which makes them not great for a lot of things, but a true toast would just be removed after a short period of time.

Liz: Got it. Thank you. Okay. Somebody says, thank you for calling out including the browser UI in the focus trap. I hadn’t considered that. Do you know of any good resources for how to do that?

Nic: I’m not sure actually. I think some libraries will handle this and some won’t. But it would definitely be something that I would test for when looking at it. I can’t name any off the top of my head, I would wanna bet that Kitty Giraudel’s a11y-dialog Python dialog library should do this, but I haven’t looked at it in a while.

Liz: Awesome, thank you. Okay. There’s another one. You suggested moving focus to an announcement text. How does that work with the rule to not move focus around in response to user interaction?

Nic: I think because there are certain components that just sort of require you to move focus around, like there isn’t really an option to have a dialog and not move focus to it because then the user would basically just completely miss that the dialog is there. I do know which rule you’re talking about, I just I’m not entirely sure that applies in this particular context. I think you probably don’t wanna be moving it around willy nilly but because this is sort of like on other site, it’s not really acceptable that the user misses it. So we wanna make sure that when we do move it in a way that’s like respectful and like not intrusive, but I’m pretty sure that we should move focus. - Thank you.

Liz: All right and thank you everyone for these great questions. Let’s see here. Should we implement the Escape button to close toasts and notifications or only for modal dialogs?

Nic: That’s a good question. I think it could be a worthwhile enhancement but obviously, there could be a complicating factors within your design, that would make it not ideal, for example, we’ve talked just like a Product page. But for example, I’ve seen, like, quick shop modals where the Product page is in a modal. So if you have a modal open, you’d wanna like consider, what kind of our modals are we gonna close with Escape, and things like that. So like I hate to give you, it depends answer, but I think in this case, it does.

Liz: Makes sense. Okay, could you follow up with a little more about how aria-live strips semantics from elements?

Nic: Yeah. For example, if we’re looking at our notification, and if a screen reader user is just listening to it on the page, they’ll hear product is an Added to Cart link, Continue Shopping or link View Cart. So they’ll hear that they’re interactable elements within it, and they can choose to interact with them, but when you announce it, a live region will basically just ignore all the stuff that you have in there. So if you have a heading in there, if you have links or buttons in there, it’ll just read the inner text. So it’ll say product has been Added to Cart, View Cart or Continue Shopping, but then the user can’t really tell it’s a link, except for hearing the words that are kind of like actiony.

Liz: Right. Thank you. All right, this one is on modals. Do you ever use modals for checkout, such as pop up modal for login, et cetera, or is that something that you would just discourage?

Nic: So I’ve largely worked with the Shopify platform, and they have, I think, just locked all of the checkout to their platform. So there’s basically no customization there. I do know that, like, one thing I really respect about the Shopify team is that they regularly have disabled users go and test all their flows. And they don’t include modals in their checkout flow as far as I know, but that doesn’t mean that you should never use it. I think, in their login situation, they will show a form in place, but they won’t show it in a modal.

Liz: Right. Thank you. Okay, what is one piece of practical advice you would give to someone starting out? I think starting out in accessibility.

Nic: Yeah, I think accessibility is really hard. I think that we kind of tell people it’s easy so that they won’t be afraid of it and then you start to learn a bit about it and it’s oh, my gosh, there is so many considerations. And not just that, it’s like sometimes people’s access needs will actually conflict with each other. So what will be good is actually good for other users. And I think the most important thing is to not be too dogmatic and just listen to feedback and accept that. It’s like, Sisyphus’s boulder like it’s a never ending task and just simply it’s part of the process.

Liz: Definitely. All right. What is the best e-commerce Add to Cart flow you have ever come across?

Nic: That’s hard to say. I think honestly, I get so surprised when anything even works.Like, it’s really sad. But when I try and test these things out,even if it works for just a single select flow, I would be so impressed. Like if there’s an Add to Cart process that kind of works just for keyboard users, even if it didn’t work for screen reader users, I’d be like, wow, they like made an attempt,because so often, it’s just like not accessible at all for any users. When it works, even in part, I get impressed. But I know that’s like a terrible bar and I shouldn’t be impressed.

Liz: All right, next one, what do you think about using an animation that moves a number up from your button to where your shopping cart total is indicated on your page so it’s like counting up?

Nic: I think I’ve seen an example of what you’re talking about. I would say, you know, you can try it out, I would definitely make sure to respect the prefers-reduced-motion query, it’s a query that lets you know if your user has turned off animations on their operating system or their browser, and by using that media query, you can make sure that you’re not showing the animation to users who definitely don’t wanna see that animation. So try it out, remember to reset filters, reduce motion, and then sort of test with disabled users if you can.

Liz: A couple more questions here. Okay, for a modal dialog, would you dismiss the dialog when the users focus exits?

Nic: So for a modal dialog, the focus should be trapped within the dialog. So basically, if you’re hitting Tab, you should kind of like cycle through all the tab-able elements in it, and then the browser UI, and then when you’re tabbing back into the page, it should just reset on the first element in that modal. For a non-modal dialog, it definitely depends on sort of the presentation of it, but it’s pretty standard that tabbing out of the non-modal dialog, you might close that modal automatically. So you can consider doing that for non-modal dialogs.

Liz: Great. Thank you. I think this might be the last question here. Should animated scrolls between two points on a page be avoided? It provides continuity between points, but could also be overwhelming, especially for zoomed users.

Nic: Yeah, I think browsers have recently given us a bunch of tools to kind of smoothly scroll between things and I think as we see that more, we do hear people with vertigo and motion sensitivity, saying that it’s not a great pattern for them. So this is definitely a situation where I would make sure to use the prefers-reduced-motion query to make sure that we’re respecting that preference, at least, and sort of consider how large that shift is gonna be. If your page is like an infinite scroll, scrolling all the products, I would probably not use that effect for anyone, but if it’s maybe like a shorter distance of the page, you might wanna use itwith a prefers-reduced-motion query on it.

Liz: Great. Looks like we have just one more question here. Is it good practice to focus a dialogs Close button first when it opens?

Nic: Yeah, so I think this can really be a point of concern for a lot of people. I think different people will say different things. Some users think it’s best to focus the entire modal and if you have a aria-labelledby on your modal, it’ll kind of like read the heading first, or what it’s labeled by first and then we’ll kind of just read all the content in the modal and the user can choose to interact with it however, whenever they want to. Some people might focus directly on that heading elementand some people might just move focus to the first focusable element. I think it could be that you’re focusing directly on that Close button instead of the modal container just ‘cause you’re adding items to your cart, you hit Add to Cart and then the next thing you hear is just like, close modal. It’s not entirely clear what has just happened. But this is definitely something that are testing on your site and whether or not your modal, like your modal design you can change what that first focusable element is.

Liz: Got it. Great. Okay, we’re gonna squeeze in one more question here. With such a varied range of disabilities, does it make sense to make flows for each and have different views and features for each?

Nic: I think that kind of like gets us into the territory of having like a different site for disabled people. And that can be a really othering experience, You can consider providing different ways of checkout, like, for example, some e-commerce sites you have individual Product pages, but they also have like, a collections list where you canadd items to cart from there or like different ways of adding to cart and perhaps in a way, you can provide different methods for the same outcome and not in a like this is for ZoomText users kind of way but if you have those options, it will. If there’s a blocking aspect on one pattern, maybe it won’t be as terrible on another pattern.

Liz: Great. Thank you so much, Nic. And with that I think we are about at time, I do wanna thank Nic for a great session. We really appreciate it. And thank you all for attending this session and for joining us at axe-con. We have quite a few more sessions the remainder of the day,so we hope y’all have a great time. Thank you.

Nic: Thanks Liz.

Liz: Bye.

Practices to consider

Below is a non-exhaustive list of things I came up with when considering the editing experience. If you have any other tips, I’d love to hear from you!

Conclusion

Some of of the tips I described fall under good usability and cognitive accessibility. In an ideal world, it would be desirable to make sure every project you work on is robust as possible, but budgets and deadlines often pose a real challenge. It is a sad reality that projects and organizations that need this work the most often have the least amount of resources, as it’s not uncommon for things like community groups or non-profit organizations to be entirely staffed with volunteers. The pay for this kind of project may be heavily discounted, or non-existent. When working on a project for free/a discounted rate, I used find myself wondering if I could cut a few corners on the CMS side in order to make things more manageable, but taking this shortcut always came back to bite me in the form of future stress. Keeping the future editor’s capabilities in mind can make this kind of work more sustainable for you and the organization.

Element Selectors

Element selectors are a way of targeting elements based on what the element is. In our school auditorium metaphor, this might be equivalent to addressing all students from a particular grade. If you say “Fifth-grade students, stand up”, you are addressing students based on what they are. An example in CSS might look like this snippet below, where we are grabbing all our anchor links based on the fact that they are anchor links. This represents the lowest level of CSS specificity.

a {
	color: blue;
}

Attribute Selectors

Attribute selectors are a way of grouping elements together based on different shared attributes. For example, in our school auditorium, we might want to address students across different grade levels based on some attribute they share. In this situation we might say something like “Students with long hair, stand up,” to address all students with long hair. We could apply our previous knowledge and combine element and attribute selectors into a more specific instruction, such as “Fourth-grade students with long hair, fifth-grade students with long hair, sixth-grade students with long hair, stand up,” but this level of specificity isn’t necessary, and is more verbose than our original instruction.

An attribute selector in CSS is enclosed in square brackets and looks like this:

[lang="en"] {
	color: blue;
}

Attribute selectors fall under the second lowest tier of specificity.

Class Selectors

You might think of a class name as a name that is assigned to an element. As individuals, we probably like to think that our given names are unique, but in practice that is rarely the case (I should know, I’m almost never the only Nic/Nick on a team)! Depending on the name, it might be that your name only appears once in a group, but it may be used to address multiple students at the same time, eg. “Students named John, stand up” is likely to result in multiple students standing up.

We can write our class names in a way to target one or more elements, depending on the wider context of our site and what we as CSS authors might need. A class name like “footer” may only be needed once per page, but a class name like “primary-button” may appear many times. The class selector begins with a period and is followed by the class name. Class selectors fall under the second lowest tier of specificity along with attribute selectors.

.navigation {
	color: blue;
}

Id Selectors

So what if we want to grab a single student? The only truly unique identifier for an element is an id (technically, you can apply the same id to multiple elements and your page would still technically ‘work’, but this can have a negative impact on the accessibility and usability of your page!) An id can be thought of as a unique identifier for a student, such as a social security number or a passport number. Theoretically, there should only be one student that has a given id, so if we want to be sure that we’re addressing a specific student, using their ID number is a more foolproof way to target them rather than saying something like “John Smith, stand up.” An id selector begins with a hash, and is followed by the id. Id selectors fall under the second highest tier of specificity.

#navigation {
	color: blue;
}

Inline Styles

Inline styles aren’t technically a selector in CSS, but they represent the highest tier of specificity. We might think of inline styles as students who have headphones on during the school assembly. Regardless of what instructions are given to them, they have their own set of styles that they are listening to. A room full of students with headphones on is much harder to wrangle than a room full of students listening attentively, so it is in your interest as a CSS author to minimize inline styles. Inline styles are directly applied to an element in the HTML.

<div style="color:red;">I'm red!</div>

Combinator Selectors

Combinator selectors are a way of describing elements in relation to another. In our student metaphor, this might be akin to saying something like “Students who sit behind the first row of students”, or “Amanda, the younger sibling of Sally from fifth-grade.” Though both are ways of addressing students in relation to one another, one is more specific than the other. Combinators are powerful and can unlock a ton of useful functionality without having to come up with granular class names, but be warned as combinators add up the specificity of all selectors in that particular combination. Chaining too many combinators should be avoided.

p + p {
	margin-top: 1rem;
}

!important

!important provides a way for us to override all of these selectors that we have previously mentioned. We might think of !important as an announcement blaring over the school’s public address system, it takes precedence over what is being announced in the auditorium, regardless of how specific the selector is. “All students involved in lunchtime incident, please come to the principal’s office” and “Student number 92374, please come to the principal’s office” are equally capable of overriding our previous rules. Like inline styles, !important is not a selector, it is applied to a declaration directly.

a {
	color: red !important;
}

What does this teach us about writing good CSS?

It’s fairly common for newer developers to be overly specific when writing CSS. I often see developers combining and chaining together long selectors that may correspond to the HTML structure of their page. A selector like #navigation > ul > li.current > .button will get you the results that you want, but it can be more difficult to understand. Even more problematic, a selector like that can be hard to extend, as you keep having to find new ways to make subsequent selectors even more specific than your previous selector. The selector is much like stating “Students in fifth-grade, of which the one named John that sits behind Sally with blue eyes.” It’s a lot to keep track of! You’ll have an easier time with CSS if you take some time to really think about what you are trying to target and how specific that selector needs to be.

How accessible is the core Stardew Valley experience?

Those of you who are web developers might already be familiar with the Web Content Accessibility Guidelines (WCAG), a series of documents on how to make the web more usable for people with disabilities. For video games, there’s a similar effort known as the Game Accessibility Guidelines, which I’ve referenced for this article. While websites and video games have major differences, they both often are interactive digital experiences, and there is some overlap between accessibility best practices for both mediums.

Despite being the product of a sole developer, Stardew Valley offers quite a few accessibility features out of the box. The level of customization for the overall user interface and controls is more granular than most other games, even those with larger budgets and teams behind them.

There are options to remap nearly every keybinding, and many mouse interactions can also be achieved via the keyboard. This is a welcome feature for those who have difficulty using a fine-tuned pointer device such as a mouse, or those who suffer from strain (like me!) using conventional mice. You can scale the user interface and the background independently up to 150% and 200% zoom, which is great for users with low vision or those who may need larger hitboxes in order to successfully complete an interaction. There is also an option to use the default hardware cursor, which is helpful for those who have customized their cursor to their needs (typically by increasing the size or changing the color).

In terms of sensory needs, Stardew Valley allows you to disable flashing lights during the occasional thunderstorm. Players have the ability to toggle certain sounds individually, allowing people to create their own custom sound experience based on their individual cognitive abilities, sensitivities and triggers. For example, blind gamers like Darrel Bowles may appreciate audio cues that would let them know that their action has been completed successfully, but gamers with certain phobias or triggers may appreciate the option to turn off particular sounds.

In terms of settings and configuration, Stardew Valley goes beyond most large-budget games, offering a wide variety of options that would allow you to configure the basic gaming experience. However, there aren’t that many options to customize the actual game itself to make it more accessible, and this is where mods step in.

The wonderful world of Stardew Valley mods

The vast majority of Stardew Valley mods are available through the Stardew Modding API (AKA SMAPI). SMAPI is an installable piece of software that allows users to load mods by placing them in a particular folder on the filesystem. Once SMAPI is installed, mods can be downloaded from a variety of places such as Nexus Mods, which hosts thousands of Stardew Valley mods alone. While some mods are merely cosmetic or offer additional content, a quick glance at the most popular Stardew Valley mods on Nexus Mods shows us that many others target specific accessibility needs.

Colors

One of the things that made me personally wary of playing Stardew Valley was its bright color palette. While I’m sure plenty of players gravitate towards the default bright and cheerful graphics, many people experience eye fatigue or migraines when looking at a bright color palette. Luckily, there’s a whole host of mods out there that offer alternative color palettes for the game maps, in every flavor imaginable. Options include, but are not limited to, the following:

• A Wittily Named Recolor makes the whole palette significantly more muted

• Starblue Valley makes everything a little more blue, an option for those who experience eye strain with too much yellow

• Natural Recolor makes the color palette more natural looking

• Vibrant Pastoral, despite its name, reduces the saturation on all outdoor maps

There are also color-related mods that explicitly target accessibility needs. Dark User Interface offers a (you guessed it!) dark mode for the UI, and can be used in combination with a map recolor. For those who like light mode but struggle with the default bright yellow-orange interface, there’s a beautiful, on-brand white and brown alternative.

A fairly common complaint from Stardew Valley players on various forums is it can be difficult to tell the difference between different object states, especially when the difference is highlighted primarily through color (Different object states can signal important information to players, such as whether an object in the game can be interacted with.) Mods such as Highlight Empty Jars address this by adding a more noticeable speech bubble on top of empty jars, or changing the empty jars to a brighter red color. Similarly, colorblind players can often struggle to tell crops apart or have issues identifying when things are finished growing, as color in the base game is often used to indicate ripeness. The SDV Colorblind Mod offers a helpful alternative for those with red/green colorblindness.

Cognitive accessibility

Playing Stardew Valley requires a certain degree of memorization. There are items you have to hunt down, seasonal crops and NPCs that have a specific weekly schedule. For gamers without cognitive issues, learning these things could be regarded as part of the game’s overall learning curve. It mirrors your growth as a rookie farmer, and your knowledge about the world grows as the seasons pass.

However, for those with cognitive and learning disabilities, it can be difficult to ever reach that level of familiarity. Having to repeatedly pause a game in order to go double check something on the wiki is not my personal idea of a great time. Lookup Anything basically offers an enhanced wiki experience within the game. It even provides contextual information, such as your current friendship level with NPCs and whether or not you’ve crafted an item before. Similarly, Ui Info Suite enhances the level of information present in the UI, making hidden game mechanics more visible and improving the information found in the default tooltips so that players don’t need to rely so much on memorization.

By default, Stardew Valley’s map is static and displays only a graphic image of the world map. NPC Map Locations adds the different non-playable characters (NPCs) to the map, with locations updating in real time as they move around. It even adds a tooltip that will let you know when the NPC will leave their current location, so that you know whether or not you have time to meet them there before they leave.

Mods that help with cognitive accessibility are some of the most popular Stardew Valley mods of all time, with download counts numbering in the millions. As Nexus Mods keeps track of unique downloads and total downloads separately, we notice something interesting. With a mod like NPC Map Locations, the unique downloads number is around 1.3 million, where the total download number is around 3.3 million, nearly three times as much. This suggests that many gamers consider these mods essential enough that they continue to return for updates to ensure compatibility. Even a single purpose mod such as Range Display (which lets you see how wide an area your sprinklers and scarecrows affect) has download numbers in the hundreds of thousands. Options to reduce the cognitive load on players are vital for cognitive accessibility and appreciated by a large number of gamers.

Reducing repetition

Another highly popular category of mods revolves around reducing repetitive actions in this game. A big part of the core gameplay loop involves repetitive actions. To plant a crop, the player needs to hoe the ground, place the seeds, and water the seeds every day, until the plant grows. Over time, a player is able to upgrade their tools to make these tasks much less repetitive, but players with conditions such as RSI or carpal tunnel syndrome may find this initial hurdle too difficult to overcome. To most players, an extra click is an inconvenience at worst, but to some, an extra click can make the game unplayable.

Many mods allow users to bypass more repetitive aspects of the game, an effective way to minimize strain. The Tractor Mod is a popular configurable mod that can drastically cut down the number of repetitive actions, with the added bonus of not breaking player immersion. A mod like this could be used in multiplayer mode to allow a disabled gamer to play on equal footing with abled players.

While early-game gameplay tends to revolve around growing crops for some initial cash, more advanced gameplay involves turning your produce into different kinds of processed goods. The Automate mod gives the player the option to remove repetitive tasks by putting a storage chest next to the machine the player wants to automate, saving the player the effort of checking on the machine. In an open-ended game like Stardew Valley where players have the choice between dozens of different activities such as farming, fishing, mining, decorating, or even romancing your favorite NPCs, mods to reduce repetition give players the control to play the game exactly how they’d like to play it.

Text-to-speech & speech recognition

This final section covers a class of mods that are less likely to fall under the curb-cut effect: those that are specifically for a disabled audience. These mods seek to either integrate with existing assistive technologies such as screen readers, or to provide a Stardew Valley-specific version of an assistive technology. Although these mods may have lower download numbers, many have a far greater impact on people’s ability to play Stardew Valley. These mods are often the only thing allowing the disabled users who download them to play the game, which would otherwise be completely inaccessible to them.

First up, we have Pelican TTS. TTS stands for Text-to-Speech, a popular method for blind and low-vision people to interact with text interfaces. This video shows off the gist of the Pelican TTS mod, though many features have since been added that allow players to customize voices for each NPC.

In a similar vein, StardewSpeak is a mod that allows for people to play Stardew Valley solely with their voice. The mod creator has put a lot of thought into how to make the player’s experience as streamlined as possible, adding in a bunch of helpful commands that make this a viable way to play the game. For example, instead of forcing the player to count the number of tiles to reach the destination, the player can just say ‘Go to farm’, and the character will automatically find an appropriate path to the farm, taking all the twists and turns required.

Last but not least, we have the Stardew Access mod, which seeks to make Stardew Valley fully playable with just the keyboard (no mouse!), and adds support for popular screen readers such as JAWS and NVDA. The creator of this mod, Shoaib Khan, kindly agreed to speak with me for this article.

Shoaib is a university student who works on mods in his free time and moderates a Discord Server called Playability to gather feedback and collect bug reports. He got into modding when LogicProXGaming, a blind Minecraft streamer he followed, expressed a need for a mod that would tell him his current health on a keypress. Shoaib rose to the challenge and eventually began developing Stardew Access as well. When asked about the reception of Stardew Access, Shoaib mentioned that he never thought so many people would be interested in a mod like this, and that he’s grateful for all the feedback that allows him to improve the mod.

This is where I believe that arguments against accommodations making games “too easy” or “for lazy people” fall flat. Imagine if you had to code an entire interface or submit a pull request just so you could play a game! Making games accessible is a tremendous effort that is unfairly borne by mostly disabled people themselves and by people like Shoaib. What a different world it would be if game developers considered accessibility from the start, and it wasn’t something that players had to hack in themselves.

Closing notes

Many people feel strongly that allowing for users to change the difficulty of the game somehow compromises the experience or the “developer’s vision”, to which I can only shrug. Being able to meet people where they are is a fundamental aspect of accessibility. Opening the door and allowing people to enjoy a game that they wouldn’t otherwise have been able to play is a good thing. I can’t believe this still needs to be said, but based on the comment section of any given article on gaming accessibility, disabled people continue to have to fight for this basic level of acceptance in gaming spaces.

User-created mods are not a replacement for first-party/developer support, for many reasons. In the case of Stardew Valley, mods only work on open platforms, not on closed platforms such as the Nintendo Switch or iOS, and many other games don’t allow for the use of mods at all. What I want folks to take away is this: the fact that people would go out of their way to create tools to make the game accessible to themselves and others highlights the importance of creating accessible gaming experiences in the first place. I am only a visitor to the big wide world of gaming accessibility, and I hope that people will continue to support and follow the efforts of disabled gamers and their advocates.

A very quick explainer

In short, if we imagine the browser as a large art or design program, using will-change promotes that element to its own ‘composite layer.’ That layer can be hardware accelerated; that is, be rendered using the more powerful GPU (Graphics Processing Unit) instead of the default CPU (Central Processing Unit). Knowing that the element will change over time lets the browser isolate that element, and should improve rendering performance. Will-change does come with the caveat that it should be used sparingly, only on elements that really need it. Offloading too many things to the GPU can slow down the page, the opposite of what we want.

The epic journey

With all that in mind, the will-change property landed in major browsers in August 2015, and I’ve been on the lookout for when to use it ever since. It might seem self-evident to apply it to commonly animated properties such as transform or opacity, but the browser already classifies them as composite properties, thus, they are known as the few properties that you can already expect decent animation performance from. So, heeding the advice of the great developers who came before me, I was cautious and waited for the right opportunity to come along.

I hoped that will-change would solve the Chromium bug where vertically centering a element using transform: translateY(-50%) would result in a blurry element if the calculated height was an odd number of pixels, but our friend will-change let me down there, it had no effect whatsoever. (I typically use Flexbox to avoid this issue now, as it sadly, still exists, seven years later).

Over time we even began to see articles critiquing will-change appear. GreenSock, a popular JavaScript animation library, published a piece noting how the implementation of will-change caused animations that had worked perfectly in the past to appear blurry, and the recommended solution (setting will-change: auto, effectively, a reset) seemed contrary to the proposed behavior of will-change.

In my mind, it was around this time where will-change became something to be wary of. For the most part, I wasn’t really writing animation code that was very complex, and could rely on well-tested libraries such as GreenSock or documented techniques such as FLIP for silky smooth animations. Browsers were only getting better at rendering performance, whenever I popped open Chrome’s paint flashing tool to ensure that stuff was on its own layer when it needed to be, things were typically looking okay out of the box. I’d reach for it sometimes to try and fix the occasional rendering bug (usually as a cudgel after translateZ(0) and backface-visibility: hidden failed) but it certainly never was the silver bullet I hoped it would be.

Get to the point already

But that all changed this week. I woke up one morning to find that a client had noted that the link animation was looking a little rough around the edges in Safari. Being a Windows gal, I fired up the good ol’ BrowserStack to take a look, and saw this. (Forgive the screencap quality, it is a recording from Browserstack after all!)

My first reaction was surprise. Wasn’t scale supposed to be one of the safe properties? Nonetheless, I reached deep into my toolbox, for the cursed artifact that I had never reached before. I may have even held my breath a little as I typed will-change: transform and waited for my browser to reload the page.

It worked! I dusted off my hands and continued on with my day, excited to have finally found my white whale, a use for the will-change property.

The mystery continues

But wait, there’s more! I know I can’t leave you all without the juicy details. What went wrong, and why was will-change able to help? In this particular codebase, we had a link, and a pseudo element is animating from a horizontal scale of 0 to 1 when the link is hovered (snippet below lightly modified for brevity). I tried dropping everything into a Codepen to see if I could reproduce it, but interestingly enough, it works fine without will-change in the default Codepen view, and shows up only in the debug view, the only view on Codepen without their wrapping code (which I cannot share).

.link::before {
	content: "";
	display: block;
	position: absolute;
	transform: scaleX(0);
	transform-origin: left center;
}

.link:hover::before {
	transform: scaleX(1);
}

In a pre-pandemic life, I might have tried harder to get the bottom of this mystery, but alas, it was everything I had in me to type up this blog post, which I’ve uncharacteristically hammered out in a single sitting. Perhaps I will never know why will-change was able to save me in this case. I’d be extremely eager to hear if other folks have had experience with the will-change property smoothing any rendering issues, my inbox is open!

PS: Happy new year of the tiger. May 2022 be kinder to us all.

Further examples (Last updated February 27, 2022)

Since publishing this article, I’ve found some other folks who have had luck with will-change resolving rendering issues. Thanks to the folks below who allowed me to share their discoveries here.

Alex Riviere noticed that when using Chrome 98 with a Macbook Pro, the last cloned item in this infinite scrolling section would cause the last element not to render. Adding will-change: transform fixes this.

Brian Cross noticed a recent issue with Safari 15 where GSAP transform animations that had worked correctly in previous versions were now leaving behind artifacts. The official GSAP team’s response was to add will-change: transform to the problematic element.

Justin Veiga came across an issue with Chrome on MacOS, where a photo enlarging animation done with transform: scale() would display with noticeable jank. Adding will-change: transform resolves this.

Translations

• Russian

The best focus styles are additive

When I was just starting out, I often received designs with no interactive states at all! In many cases, it was on me to come up with hover and focus states. This led to me applying the same styling for all these states. While this is certainly better than having no focus states at all, the best focus states need to work in conjunction with other states. This is especially critical for things like checkboxes, where oftentimes a designer might design a hover or focus state that only works when the input is unchecked, but is incompatible with the checked/selected state.

By treating focus states as additive, you gain another benefit — on slower internet connections and devices, users may use the focus state as an indication that yes, the control has actually been pressed. On sites that are slow with high Time To Interactive metrics, I often find myself confused about whether or not a site is usable yet, and having an interface with carefully considered states may alleviate some of this confusion.

Rely on affordances

An ‘affordance’ is a feature or property of a design that suggests how it is supposed to be used. In web design, radio buttons and checkboxes are both UI patterns that allow a user to select options. Checkboxes allow for multiple items to be selected, and radio buttons offer a single choice amongst the options. While their exact appearance differs across browsers, default browser radio buttons are always round and checkboxes are square. Similarly, although focus styles differ between browsers, all of them are some form of outline, so it’s best to design focus styles with this in mind.

I recently came across a case in the wild where designed focus styles that lack affordances were an issue for me. I’ve mocked up a recreation of the experience in the screenshots below.

This site had custom focus styles for their buttons, where the outline was removed and the background color of the button was changed. While the colors in question meet all contrast requirements, the button was not previously visible until the user scrolled, so it took me a bit of tabbing back and forth to realize what had changed. Users who rely on browser zoom may also encounter issues with this as well, as their viewport sizes may prevent them from seeing the previous unfocused state of the control. By relying on affordances and design conventions, we can ensure that the focus styles make sense out of context and that we aren’t relying on the visual difference between the unfocused and focused state.

Consider adding a little bit of breathing room

Designers often request that focus styles be removed because a thick ring that butts up against the control isn’t the most visually appealing. For things like navigation links, you could consider adding padding to the link to ensure that there is some space between the outline and the content. This not only adds more breathing room to the design, but it also improves accessibility by increasing the tappable area of the control.

If tap target size isn’t a concern or changing the padding isn’t feasible, you could use the outline-offset CSS property, supported in all modern browsers. All you need to do is pass in an offset distance, such as outline-offset: 0.25rem;, and the outline will be drawn the specified distance away from the element. Alternatively, you could utilize multiple box shadows by having a very thick box shadow in the color you would like the outline to be, and layer a box shadow the color of the background on top of it! (I learned this trick from Eric Bailey’s very cool slides on focus styles.

button:focus {
	box-shadow: 0 0 0 0.5rem white, /* background color here */ 0 0 0 0.75rem blue; /* outline color here */
	/* this results in a blue outline 0.25rem wide,
   offset 0.5rem from the element, as pictured previously! */
}

Another reason why you may wish to offset the focus: if you have a element against a background where the contrast ratio just barely meets the requirements, it can be impossible to find a third color for the outline that also meets contrast requirements against all adjacent colors. By adding an offset, you only have to worry about the contrast between one color, the background.

Dealing with overflow: hidden

Sometimes, even default outlines may be unintentionally removed when the parent of the interactable control has overflow: hidden on it. This can happen on things like card user interfaces, where using overflow: hidden to clip overflowing content will also remove the outlines. You could try consider using a negative value passed to outline offset, such as outline-offset: -.25rem; or an inset box shadow (eg. box-shadow: inset 0 0 0 0.25rem red;) in order to render an outline without changing the css on the parent element.

When using sticky elements, use scroll-padding-block-start to ensure your focused elements aren’t covered.

If your design contains sticky elements, it’s possible for the sticky element to inadvertently overlap your focusable element.

Getting an outline to hug the element

Another reason why designers may request for the focus outline to be removed is because the default outline ignores rounded borders on elements. Thankfully, we aren’t actually limited to using the outline property for custom focus styles! This issue can be solved by using box-shadow instead of outline to account for the border radius.

It’s probably best to avoid using outline: none, even if you override focus styles

Certain CSS properties are overriden in Windows High Contrast Mode, including borders, background colors and box shadows. A lot of custom focus styles are reliant on using these three properties and hiding the outline. In order to support high default contrast mode, Sarah Higley advises that we don’t remove the outline completely with outline: none;. Instead, we can set the outline color to be transparent, so that the outline is invisible when not in high contrast mode, but overridden correctly in high contrast mode, where the transparent color will be replaced with a color set by the user. You could preserve the existing outline styles with outline-color: transparent;, or define a width and style with outline: 0.25rem solid transparent;.

Final Words

Focus styles are definitely something that should be considered from the beginning of the design phase. Because consistency and convention are key to designing successful focus styles, adding focus styles may not take that much more time to design and implement, but would add a lot of value in terms of making the interface useable for disabled users.

I certainly don’t think this piece is either the first or last piece of writing on the subject of focus styles (curse you all for stealing the good focus related puns!), but hopefully it gets the gears turning in your head for possible focus style options. I invite you to read up on the articles featured within this post and below, and, as always, test with users!

Further Reading

• Focusing on Focus Styles by Eric Bailey
• Indicating focus to improve accessibility by Hidde de Vries
• :focus-visible and backwards compatibility by Patrick H. Lauke
• Accessible Focus Indicators: Something to :focus on by Aaron Pearlman

Introduction (0:00)

Hello everyone! My name is Nic Chan and I have been contributing to the Maps 4 HTML Community Group over the past year, with a particular focus on the Uses Cases and Requirements report. Today I will be presenting on the accessibility of existing map widgets and tools.

Definitions (0:19)

Before I get into the details of the analysis, I’d like to lay out some definitions that will frame this discussion. The map tools discussed today fall into two general categories, widgets and client-side mapping APIs. Widgets refer to an embeddable map, typically in an iframe or something similar, that requires minimal code to implement. These include things like the Google Maps embed that small business owners may use to share their store location. Client-side Mapping APIs are JavaScript libraries that allow website developers to create more customized map viewers. They typically require the developer to do more configuration and instantiation work, with the benefit of offering more control over the end result. You would typically find these as a part of web apps like storefinders or delivery services.

In this presentation, I’d like to frame accessibility as the degree to which these maps are usable by disabled people. Some contexts may use the term accessibility to encompass other things, like cost and size of these tools and how that pertains to access, but in this case we will be focusing on the usability aspect, and especially how these mapping tools measure up to our next term, WCAG.

WCAG, short for Web Content Accessibility Guidelines, is a series of guidelines developed by the W3C in order to provide a shared standard for developing accessible web content. It is important to note that the WCAG is not the be all and end all of accessibility. When it comes to things like maps, a tool could meet every single criterion, but still not be accessible. There are many outstanding questions (which will be discussed in greater detail by other presenters and panelists) about what would constitute an equivalent experience to what a map can communicate for low vision and blind users. However, it is still worthwhile to examine the existing tools with the WCAG in mind, so we can account for other disabled users beyond low vision and blind users, such as people who have motor impairments. By looking at these existing tools, we can determine any common patterns worth adopting for a native HTML map element.

Not all WCAG criterion are relevant to web maps, so I’ve pulled out some of the most applicable and interesting ones, where the map tools meet these criterion with varying degrees of success.

Tools Reviewed (2:40)

The tools reviewed today include both widgets and libraries from vendors like Google, Bing, Apple, MapBox and TomTom, as well as some open source solutions with OpenStreetMap tiles. For a full breakdown of how each tool measures up and the details of each criterion, please visit Robert Linder’s full evaluation at tinyurl.com/wcag-maps. Robert is a member of the Maps4HTML Community Group, and his contributions have been invaluable.

With that out of the way, let’s begin!

Non Text Content (3:13)

5/11 tools failed.

This criterion states that all non-text content has an equivalent text alternative. None of the map tools offer any meaningful text alternative to the map content by default, so on that front, all of the maps would fail, unless context is provided by the site developer. As mentioned earlier, what this alternative content could look like is a very complicated question that depends on the content of the map, and warrants larger discussion.

Because developers and authors may choose to provide additional context, when evaluating this criteria, we are focused on text alternatives to controls other than the map itself. In this case, this criterion also applies to things like alternative text for logo images and making sure all icon buttons are labelled descriptively for screen reader users.

As an example, maps often use the plus and minus symbol to indicate zooming in and out. As a sighted user, I can see the visual context these buttons are in, and I can also see that the map zooms in and out when I press the buttons. However, if you just hear “Plus Button”, the context is a little more unclear, it could mean adding a pin to the map, or changing the quantity of another control. We can include context without changing the visual appearance of the control by adding things like alt text to images, or an aria-label to the control. A possible solution to resolve this example might be to add an aria-label to the button.

Info & Relationships (4:48)

11/11 tools failed.

This criterion requires that all information, including a control’s state or structure, can be determined programmatically or is otherwise available through text. Tools often failed to label the map’s structure as a distinct piece of content and as a control. A map generated by these tools is not just a static image, it is a control in and of itself. When the map has focus, most tools will allow you to do things like pan and rotate the map using keyboard shortcuts or your mouse pointer. Thus, the map needs to be labelled so that it is identifiable as a control, not just an image. In tool authors’ defense, there isn’t a set standard or consensus for how to approach this yet, as ‘map’ is not yet a valid component role, so there may be uncertainty on how to appropriately label this map container. The other most common reason for failure is the lack of attention paid to control state. For example, all of these web maps allow users to zoom in and out to an extent. Once you’ve hit the zoom limit, the appropriate control should be disabled, but very few examples communicate this programmatically, and most only adjust the styles. Furthermore, screen reader users will often have no idea of the current zoom level. Bing stands out amongst the examples as it announces the current zoom level in addition to the buttons state, so a user of an audio interface will always know what the current status is.

Contrast (6:21)

9/11 tools failed.

To pass this criterion, all text should pass a minimum contrast ratio of 4.5 for regular sized text. The contrast ratio refers to the contrast between the text color and the background color. Because many widgets do not allow for color customization, having accessible defaults would go a very long way in terms of ensuring map accessibility. This contrast criterion can apply to both the map controls and the actual map content. Some maps had text buttons that did not meet the contrast ratio. Fixing this is as simple as changing the text color on the buttons. Most maps had contrast issues within the map content, particularly with the labels for bodies of water and minor roads, such as in this example here. This screenshot shows the ocean filled in with a light blue color, but the text on top of it that says ‘North Atlantic Ocean’ is a medium blue, and it never gets any darker or larger no matter how much you zoom in. Maps are in a tricky position as color hierarchy is very important for establishing focal points, and there is a need to deprioritize certain map features to avoid making the map too noisy. When a map is zoomed out, it is understandable if some minor labels are below the average font size, or have lacking color contrast. However, when a map is zoomed into an area, a good map may have these minor labels take visual priority and be displayed larger and with more contrast. Some maps included a thin white outline around each label to increase the text contrast, a technique that is commonly used in closed captions for TV.

Keyboard (8:02)

7/11 tools failed.

Every functionality that is available to mouse or touch users must also be available for keyboard only users. This includes all interactable controls, as well as functions activated by pointer gestures, which most maps do have. Most failures in this instance are due to the use of non-native controls. When a semantic element like a HTML button is used, all the behaviors that are expected of the control are handled automatically by the browser. It is very common for developers to add a click handler to a div element and ignore the other required behavior. Some custom buttons are not able to be accessed by hitting the tab key and cannot be activated because they cannot be accessed at all, whereas others can be focused, but do not have any means of activation through the keyboard. A user with a pointer device can pan across the map by dragging the map interface. Some maps lack a way to do this with the keyboard, either because the map container is not focusable, or because they lack the keyboard shortcuts necessary.

Character Key Shortcuts (9:09)

1/11 tools failed.

This criterion states that if a keyboard shortcut is implemented using character keys, then at least one of the following is true: A mechanism is available to turn the shortcut off; or A mechanism is available to remap the shortcut to use modifier keys such as shift, control, alt, or The keyboard shortcut is only active when that component has focus. This criterion exists to prevent conflicts with assistive technology shortcuts and web interface shortcuts. The NVDA screen reader uses arrow keys to navigate text, and it may conflict with the use of arrow keys to pan and scroll the map. None of the web maps we analyzed used techniques #1 or #2. The web maps that have shortcuts and passed this criterion have opted for technique 3, only allowing keyboard shortcuts when the map container has focus.

Focus Order (10:06)

2/11 tools failed.

To pass this criterion, elements must receive focus in an order that matches the content reading order. In English and other left-to-right languages, we have an expectation that elements will be interactable from left to right, top to bottom, in the same order we read text.

Here is a diagram which displays the focus order of the Google Maps embed. The numbers indicate which element receives focus in what order. The first focusable element is the map container, which makes sense as the focus order should go from outward to inwards. Next is the Terms of Use button, which is in the bottom right hand corner. After that, comes the View Larger map button, which is in the opposite corner, in the top left. We return to both zoom control buttons in the bottom right, and finally, the unlabelled toggle satellite imagery button in the bottom left corner. In this case, the developers used styles to position the controls arbitrarily. Without proper focus order, the experience of tabbing through the map component is quite jarring and unnecessarily disorienting to bounce from corner to corner.

Focus Visible (11:16)

7/11 tools failed.

This criterion is related to the previous one. The focus ring is an indicator that shows which interactive element currently has focus, an example of which is shown here. We can see the zoom out button currently has focus due to the thick black ring that Chrome applies. It is present by default in all browsers, but is common for developers to remove this indicator without replacing it with their own styles. In combination with the previous criterion, this criterion is serious enough to render a map component unusable for sighted keyboard-only users, because there is no way for them to determine what element is currently selected.

In some cases, the focus isn’t persistently visible, which is due to the addition of scripts that remove the outline once the element is focused. This criterion is an example of the default behavior being accessible, and the developers have overridden this default behavior to make an ultimately inaccessible design choice

Language of Parts (12:21)

9/11 tools failed.

The requirement to pass this criterion is fairly simple, all it requires is that the content’s language is included in the markup. This is important for many accessibility reasons, such as making sure screen readers read words with the correct intonation, and can be useful for features like on-the-fly language translation. Despite the fact this criterion is simple to achieve, many vendors fail to implement this. Passing this criterion is as simple as adding a single lang attribute to the containing element, and lang attributes to text in other languages.

On Input (13:11)

2/11 tools failed.

This criterion states that changing any setting in a user interface component should not trigger any changes of context unless the user has been warned about it. In layman’s terms, if a control is used, there shouldn’t be any unexpected side effects like changing the viewport size. Here we have a gif where the up and down arrow keys are being used to pan the map, but unfortunately the viewport scrolls up and down as well. This can be quite disorienting, so it’s important to test for side effects like this.

Conclusion (13:46)

Building accessible web maps is no easy task. The base level of accessibility for existing web map solutions is quite poor overall, and no one widget or library stands out as being far superior to the rest. Criteria where almost every tool fails are often due to the lack of standardization, and this is where having a native HTML map element could really set the bar for what map widgets should strive to be.

Regardless, there are quite a few quick and easy wins to be had. I hope any developers who work with these map libraries can consider implementing some of the low-hanging fruit I’ve brought up here.

Thank you! If you have any questions about the material covered, feel free to reach out to me at nic@nicchan.me.

Methodology

For this article, I chose to test the themes for a specific task using two testing methods. First, I would try to add a product to my cart and reach checkout with my monitor obscured using only the NVDA screen reader on Chrome, and then I conducted the same test with the display unobscured but with the keyboard only, no mouse, trackpad or other pointer devices. This could be described as a simplified version of a task-oriented walkthrough.

The list of themes consists of every single theme on the Shopify theme store home page, pulled from some time in April. 32 themes were tested in total, and testing was completed sometime in May, so bear in mind that some themes may have been updated since then, especially with increased discussions about the Domino’s Supreme Court case.

Where a theme had more than one color preset, I opted to test the first one. Most themes have 3-4 presets and the difference between them usually consists of different configurations of fonts and colors. While I certainly think that the choice of fonts and colors can be very revealing in terms of demonstrating a developer’s commitment towards accessibility, almost all themes allow the merchant to change the site’s fonts, font sizes and color palettes; thus merchants are able to improve these kinds of inaccessible theme defaults. As a result, I did not conduct any automated testing for things like color contrast or font sizes on these demo stores, and I only focused on whether or not I could complete the task at hand.

If at any point, I lost track of focus for more than a few tab stops, I would consider the keyboard test a fail. Your users will not have enough patience to debug your website’s problems, even if I personally continued trying in order to determine further issues with the theme.

Testing Steps

1. Land on the homepage
2. Using the main navigation, try to navigate to a collection page. If the navigation contains any submenus, the collection should be selected from a submenu. Expandable elements are often coded incorrectly and do not consider anything beyond the mouse/trackpad experience.
3. From the collection page (essentially a page where multiple products are listed ), try to navigate to a product that is not the first product on the page.
4. If a product variant (size, color, etc) was available, try to select something other than the default variant. This is often where theme developers will try to implement custom form controls, which are prone to accessibility failures.
5. Add the item to the cart. While some themes contain ‘Buy it now’ buttons that immediately take you to checkout, a user may want to purchase more than one item, thus we should test the cart process.
6. Navigate to the cart (this may be a cart component on the same page or a separate page depending on the theme)
7. Review the order and press checkout. The test ends here, as the Shopify checkout is standardized and is rigorously tested for accessibility by Shopify.

Common Points of Failure

When asked why they do not bother to make accessible websites, developers often complain that it is too difficult to make things accessible because of the many niche bugs that occur with particular screen reader and browser combinations. In my experience, this couldn’t be further from the truth. Of all the failures I encountered, not one was due to an edge case scenario with my browser/screen reader combination, and the vast majority of errors came from ‘low-hanging fruit’. These kinds of errors are not difficult to fix. Semantic HTML and appropriate use of CSS can resolve most of these issues without complicated hacks or dependencies. Below is a summary of the most common reason why themes failed, with some resources that can help you learn how to resolve these common issues.

Results Tables

Horizontal headers represent the developer of the theme, and vertical headers represent where in the testing process the first accessibility failure took place. The later on in the process, the “better” a theme is, but given that the process of purchasing an item is integral to an e-commerce store, anything below a “pass” should be unacceptable.

Navigational failures

Refers to when I could not even navigate to a different page due to missing styles or inaccessible menu components.

Product failures

Refers to when I could not navigate to a product from the collection page or could not select a product variant.

Add to cart failures

Refers to when I was not redirected to the cart after adding the product to the cart, or any checkout-preventing errors within the cart.

Analysis

I didn’t want to critique individual theme developers with this exercise, but I did notice that themes built by Shopify performed noticeably better than than third-party themes. While many larger third-party developers had frequently asked questions or pages on their websites about accessibility, these pages often had expressed superficial commitment, and placed the burden on disabled people to report all errors, without making any effort to make these pages themselves accessible. You can see what a predicament this places disabled people in, and it allows accessibility to be deprioritized by false statistics (ie. “We haven’t had any complaints about this!”)

On the other hand, Shopify’s accessibility team is small but mighty. Scott Vinkle and Devon Persing are both wonderful people who are committed to advocating for accessibility beyond their roles at Shopify. The codebases at Shopify are an order of magnitude larger than those by the average theme developer, and the fact that Shopify still came ahead in these tests is a testament to both their hard work and Shopify’s increasing commitment to accessibility.

It’s vital for Shopify to continue to model best practices. When reviewing the source code for the themes, I observed that many theme developers would often copy the markup and JavaScript for complex components from a Shopify theme to use as a functional starting point for their themes. Because of this, Shopify’s theme accessibility efforts not only benefit stores that use Shopify’s own themes, but also, the themes built by developers who seek to emulate Shopify’s work.

Theme developers should not regard Shopify’s relative successes in accessibility as a case of ‘let’s bring on a single person to do all of the accessibility for us!” It should never be the burden of a single individual to ensure accessibility. Company-wide buy-in is necessary not only because it takes only one small error to render a site unusable, but more importantly, the people who do work that falls under the umbrella of ‘Diversity and Inclusion’ should not be placed in a position where they are seen as constantly rejecting and critiquing the work of other people in the company. When we move beyond this idea of just ‘compliance’ and integrate accessibility holistically into the entire process of building things, we might finally be able to move the field forward.

Finally, let’s revisit the initial question. What sort of options are out there for a merchant who is looking for an accessible theme? Scott tells me that so far, Debut, the theme that all stores start with, has undergone rigorous user testing and is updated to meet WCAG 2.1. Other themes by Shopify will undergo the same process eventually, but I’ve already noticed improvements in the time it’s taken me to write this article. Sometime in the future, baseline accessibility requirements may be imposed on all themes and apps within the ecosystem, so it’s wise to start thinking about accessibility now. Until this day comes, the options are fairly limited if a merchant wants to pick a WCAG 2.1 compliant theme - either use Debut out of the box, have a developer experienced with accessibility customize it to your needs, or opt for a custom theme. I hope that more developers in this space will see the need for options, and rise up to the challenge.

On ‘Disability’

When I was a child, my understanding of disability was very binary and limited. You were either disabled or not disabled; my younger self might imagine someone in a wheelchair, or someone with a prosthetic limb. My understanding changed entirely when I met Maddy Ruvolo, a disability activist whom I had the pleasure of meeting in college. Maddy was the co-founder and president of the school’s Disability, Illness, and Difference Alliance, and she wrote her senior thesis on chronically ill youth and the role that Tumblr played as a model of disability community.

Because I am the kind of big nerd who enjoys reading her friends’ theses, it was through her and the many subsequent hours I spent browsing Tumblr that I began to reevaluate my limited, abled conception of disability. It may be tempting to try to categorize experiences of disability into three distinct categories; [1] what we might call more visibly disabled people, [2] chronically ill people, and [3] mentally ill people. Over time, I came to understand that while there may be significant differences between these three experiences, there is also significant overlap among their access needs and struggles. The boundaries between these three categories are so blurry that we cannot afford to make generalizations about what we perceive these groups to be.

What is Tumblr?

Tumblr, a microblogging platform popular amongst young people, was always a place where niche communities could flourish, and discussion of topics such as race, sexuality and gender was frequent and widely shared. Among these communities were those that discussed various aspects of disability, particularly chronic illness and mental illness.

Unfortunately, Tumblr’s own terrible web accessibility has excluded a very large portion of the disability community, primarily by being completely unusable to those who use assistive technologies such as screen readers and keyboard only users. As a result, the discussion surrounding disability on Tumblr has been shaped by the absence of disabled people who were more likely to be experts in the technical facets of web accessibility. While I think that Tumblr (and all platforms) should commit to complying with the Web Content Accessibility Guidelines (WCAG), there are still valuable lessons to be learned by examining the idea of accessibility from different, non-technical perspectives.

Tumblr and Third Party Apps

Often maligned as ‘the blue hellsite’ by its own user base, Tumblr as a platform has always had a hostile relationship with the majority of its users. Tumblr users reading this post may remember the time they removed the ability for users to publicly reply to each other’s posts. Tumblr’s vague official announcement post did not go over well, and users were left to speculate whether the new instant message/direct message (DM) feature was really going to replace the ability to reply. Imagine if Twitter removed the ability to respond to tweets and insisted that DMs were a replacement! Although Tumblr did eventually bring replies back, this was just one incident in a long series of disappointing management decisions from Tumblr. Most recently, Tumblr’s mass purging of ‘adult content’ has de-platformed many queer creators, regardless of whether or not their content actually contained ‘adult content’, further contributing to the toxic idea that queer people are inherently inappropriate for children.

Long-time Tumblr users may also recall using Tumblr-specific extensions in order to improve their browsing experience. Tumblr Savior was among these extensions, and for many users, it lived up to its name and made Tumblr into a usable experience. Originally released in 2008, Tumblr Savior functioned similarly to Twitter’s muted words, though it was even more powerful because it searched the full contents of the HTML when deciding whether or not to hide a post. This muting mechanism was helpful as instead of relying on the poster to tag posts with specific tags, Tumblr Savior would hide anything that mentioned the offending topic within the body of the post.

Most abled users would use this blocking feature to hide things like TV show spoilers or mentions of a fandom they didn’t particularly care for, but many disabled people considered Tumblr Savior a necessary tool in order to use the platform at all. For example, people with motion sensitivities or conditions like epilepsy could choose to universally block all gifs in order to avoid potential triggers. Similarly, people who experience trauma/Post Traumatic Stress Disorder (PTSD) or certain phobias could avoid topics which may induce panic attacks and other negative responses.

Muting mechanisms and preference controls are vital tools for accessibility. Platforms that host content, whether they be social media networks, news outlets or something else entirely, have an obligation to allow users to control their own experiences. Whether it be someone hoping to browse Instagram without triggering their eating disorder, someone trying to keep up with their relatives without being subject to a seizure-inducing gif, someone avoiding the details of a recent celebrity suicide for their own mental health or someone with a serious phobia of balloons, we all have a right to control what content we consume.

Third-party Tumblr apps once provided a number of other features that allow disabled users to overcome Tumblr’s shortcomings. Missing E and XKit (both of the original apps are now defunct, though XKit lives on with a new team behind it, they’re always looking for contributors) were two of the most popular more full-featured extensions. In addition to providing muting and advanced blocking implementations for better content filtering and harassment prevention, these apps contained features such as one click reblogging and auto-tagging. One-click reblogging allowed for users to share a post to their own blog very quickly, and auto-tagging would allow users to apply appropriate tags to a post with minimal hassle. In her thesis, Maddy argued that because users with chronic illnesses often experience fatigue issues, features like one-click reblogging enabled people who may be too exhausted to leave the house to engage in some form of social interaction, however small, while still accommodating for their followers’ triggers by automatically tagging posts when necessary. As abled people, we often regard features like this as a convenience for most users, but they can be necessary for disabled users to experience the app at all.

You might think that Tumblr would look favorably upon the developers who spent countless unpaid hours working to make their platform more usable, but instead, Tumblr actively waged war with third-party app developers. In 2011, users with the Missing E extension installed were greeted with a pop-up that warned against using a ‘browser hack’, which Tumblr claimed could lead to disastrous consequences such as data loss. Tumblr ultimately banned Missing E, despite the developer’s attempts to work within the guidelines that Tumblr had set.

In 2017, half a decade later, Tumblr finally released a post filtering feature. In comparison to some of the third-party extensions, Tumblr’s solution only enabled users to filter by tags. Relying on users to tag things consistently is inferior to full text search (imagine if Twitter’s muted words only worked for hashtags). The more comprehensive Chrome extension Tumblr Savior still has over 150,000 installs today despite the fact it no longer works consistently and was last updated over a year ago.

The Unsemantic Web

Generally speaking, platforms like Tumblr are often hostile to third-party developers, and by proxy, disabled users. This can manifest in ways that are overt, as with Tumblr’s active attempts to block third party extensions, or in more subtle ways, such as when a platform makes engineering decisions in order to achieve some goal like improving developer convenience or thwarting adblockers, but with negative consequences for accessibility.

Facebook’s ‘Sponsored’ link is a particularly egregious example of this. The sponsored link is a label on a post to indicate the content is sponsored. In order to display the word ‘Sponsored’ without directly displaying the word in its entirety, for fear of allowing detection by ad blockers, Facebook added dozens of extraneous letters in nested <span> tags in hopes of making it difficult for ad blockers to parse the text. Until recently, the redundant code also made it difficult for assistive technologies to parse the text, resulting in some screen readers reading out ‘S-P-O…’ etc. as individual letters. After several months, Facebook appears to have resolved this (at least for the NVDA screen reader on Chrome), a minor victory.

Keeping things simple and semantic is key to writing good code. ‘Semantic’ in a web development context generally refers to using the right kind of HTML element for the job. Using the proper elements in the right context provides affordances for things like search engines and assistive technology, allowing them to convey meaning to the end user. In Facebook’s case, their 50+ line monstrosity can be replaced with a single tag, <span>Sponsored</span>. Overengineered solutions can make things inaccessible to users and dramatically increase the size of the page, slowing down the website and using up more data.

In addition to writing bloated, unsemantic code in order to thwart adblockers, Facebook’s code architecture decisions made it difficult for third-party developers to create accessibility fixes. For example, Facebook uses a CSS-in-JS solution that generates class names. CSS is a styling language that changes the appearance of elements on the page. We typically attach these styles through class names, so writing something like .box { background-color: red } would make all elements with the class name ‘box’ have a red background.

Third-party developers often rely on consistent class names in order to create extensions that last beyond a single update, but Facebook has prioritized their engineering needs over their end-users. Creating a scalable, easy-to-use naming system is a difficult task, as applications like Facebook have several thousand unique components that must be named in order to prevent styles from unintentionally affecting other parts of the page. Many CSS-in-JS solutions, including the one Facebook has chosen, take care of the naming process for you, and thus instead of having names like ‘box’, we get non-descriptive names like ‘q_q25znkklu’, as found in the screenshot above. While it is not necessary for class names to be meaningfully named, generated class names are often regenerated when changes are made. Any third party extensions that rely on those class names will have to be updated to accommodate the change, even if the actual styles themselves do not need to be updated. The most popular themes for Facebook are updated several times a week in order to keep up with Facebook’s changes. Maintaining a theme for one of these applications is a thankless and time-consuming task, and many developers are forced to give up.

Although changing one’s theme to feature Game of Thrones characters is likely not done to improve accessibility, many user-developed custom stylesheets are designed for accessibility purposes. Dark themes can reduce eye fatigue and headaches for people who have to look at their screens for a long period of time, and can be especially helpful for those with light sensitivities and or those who experience migraines. Fonts can be changed to better support readers who require larger fonts or fonts with better contrast (such as for dyslexic users), and user interfaces can have distracting (animated or otherwise) elements removed in order to help people with ADHD or other sensory disorders better focus on the task at hand.

As web developers, our first impulse might be to try and distill all these experiences into an actionable list. As tempting as it is to treat accessibility as a checklist, it does not work that way. As humans, we are complex and our access needs may conflict with one another. For example, I personally prefer dark themes and have a screen color temperature adjuster on at all times in order to manage the eye fatigue and headaches that often happen when you spend all of your time staring at a screen. However, some people experience glare, blurriness or streakiness when looking at light text against dark backgrounds, and dark themes would therefore be unusable for them. Even in the rare case that a platform provides both dark and light theme options, the size of a platform like Tumblr guarantees that some people will have conflicting access needs. People with multiple disabilities often have to make sacrifices by choosing between features that may support them in one area, but worsen another.

I don’t believe that developers for large platforms like Facebook and Tumblr are sitting in a room discussing how to make their sites as inaccessible as possible. They face attacks from a variety of bad actors, and their ever-changing, complicated codebases may be part of an active attempt to thwart these attacks. However, we cannot let our desire to fend off potentially malicious technology override the needs of actual users.

When we make websites difficult for bots and scrapers to use, we have the unintentional side-effect of making website difficult for assistive technologies to use. Tools such as screen readers and magnification software are widely classified as assistive technology, but custom extensions and stylesheets should also fall under that category. If you can’t build something that accommodates the needs of users with disabilities, then the very least you can do is to build it in a transparent way that allows for them and their advocates to fix it on their own. When a platform is engineered for clicks and engagement, we prioritize profits over the people we are trying to serve, ultimately leading to unethical design practices. In short, the web is not a compile target and we should not treat it like one. Our users are not our enemies, and it should not be acceptable to exclude people with disabilities for profit or developer convenience.

Practicing Accessibility

To recap, Tumblr as a platform has blatantly ignored the requests of it’s disabled users, and was hostile to third-party developers that made it’s platform usable. While Tumblr as a platform has very much served as a lesson for what not to do, Tumblr’s disability community has developed unique strategies in order to cope with the inaccessibility of the platform, modelling what we might now call ‘inclusive design’ before the term was coined.

For those who might not know, individual Tumblr blogs live at their own URL, and can be styled using different themes, much like a MySpace page or a Wordpress blog. So while the Tumblr dashboard and application that bloggers use to make sites may not be compatible with most assistive technologies, individual blog owners can make their rendered sites somewhat more accessible through choosing more accessible themes. (I quantify ‘somewhat’ here as Tumblr has made many baffling decisions that make full compliance with the WCAG almost impossible).

Tumblr’s theme store offers a wide variety of themes, ranging from paid premium themes made by professionals and agencies to themes made by hobbyists who learned how to code by copy-and-pasting snippets from each other. In terms of accessibility, there is almost no correlation between the cost of the theme and how accessible it is. Sure, you have many themes built by hobbyists that are using 12px white fonts on pastel pink backgrounds, but it is painfully common for websites built by professionals to not be accessible at all. It is much easier for a simple theme built by a passionate hobbyist to be built accessibly by virtue of not adding the bloat and fanciness we are used to seeing in web projects these days.

Within the Tumblr theme building community, which is largely populated by non-professionals, certain practices have been created for accessibility purposes. For example, many themes offer the ability to display a spoon meter (derived from Spoon theory, a popular disability metaphor) or other variants such as stylized health meters and battery indicators. In a world where social media places immense pressure on us to be constantly available and performing our best selves, there is power to be found in being vulnerable and disengaging from the demands that social media places on our time. Declaring ‘I am low on spoons’ and having that be respected and accommodated by one’s followers is a profound action, and the ability to set boundaries is necessary in order to allow disabled people to participate in online communities.

Tumblr theme developers have often repurposed certain platform features in order to improve accessibility. An interesting example of this is the {TagsAsClasses} functionality. The {TagsAsClasses} feature outputs tags on a post as CSS classes that can be referenced for styling purposes. Although this feature was likely created for more commercial purposes, users have utilized this tag for a variety of access needs. Users can add support for multilingual blogs by tagging posts with right-to-left languages (such as Arabic) appropriately. It can also be used to allow users to accommodate for their followers’ needs by tagging things for common phobias or triggers such as #motion warning, #no captions, #spiders, #gore, and hiding that content or placing it under a ‘Read More’ cut.

Several themes offer a wide variety of settings in offer to support as many different kinds of reading experiences as possible. Amateur theme developers share snippets for light and dark mode toggles, bold/italic style removers and font family switchers (to toggle between fonts that users may find more readable, as people have different preferences). While their implementations aren’t always perfect, unpaid amateurs, many of whom are students, are putting in massive amounts of effort to improve accessibility. We, as professional developers, should take pause, as we often fail to do put in even minimal effort. We absolutely need to do better.

One final practice that I would like to mention is the idea of ‘Community accessibility’ as it is practiced on Tumblr. In this case, ‘community accessibility’ refers to the practice of individuals contributing their own time and ability to improve accessibility when the original creator is unable to. For example, someone with fatigue issues may need to create a long post but be unable to type. They can record a video of themselves and tag the post #accessibility request, in the hopes that one of their followers will add transcripts or captions to the post, which can then be shared with the video.

Another common practice is to add image descriptions to images, as Tumblr has never had proper alt text support. Tumblr’s reblogging system facilitates this kind of interaction in ways that other platforms do not, as another user’s image descriptions can be grouped with the original inaccessible image. Community accessibility improves the overall degree to which disabled users may participate in the community, without placing the burden on those disabled users themselves.

What would it look like if we encouraged and facilitated community accessibility when building our own platforms? Media-sharing platforms could allow users to submit accessibility requests for captions or alt text, or allow them to be added in later. (I can’t count the number of times that I’ve forgotten to add alt text to a tweet.) Platforms that facilitate meetups or review services could allow users to enter accessibility information, so that people who use wheelchairs won’t have to suffer the humiliation of turning up at an event only to find it completely inaccessible to them. At the very least, platforms could facilitate requests for accessibility information anonymously, as disabled users shouldn’t have to open themselves up to harassment from defensive event planners. The potential for improvement is limitless and we can do better at every step of the process, from idea conception to development.

In terms of tangible things that we can start to do, I have a few suggestions. For those of us in tech, we should reflect on the state of our projects, as SeriousEats has done in this thoughtful public blog post. For social media users, it may mean thinking about the ways we interact with social media (Tumblr or otherwise!), and committing to improving accessibility in the content we create. No matter what level of knowledge we have, above all we need to listen to and center the conversations that disabled people are having.

Building accessible platforms does not start when we begin designing user interfaces (UIs); we need to be thinking about this much earlier on in the process. Caring for the collective physical and mental health of our communities is integral to practicing disability justice. We cannot build platforms that are technically accessible but facilitate the harassment and ongoing traumatization of marginalized communities and then call our jobs done. The power of the internet is transformative, and when we make spaces inclusive, we change lives for the better.

Multiple section instances

For those who might be unfamiliar, the Theme Customizer is basically Shopify’s answer to a page builder. In the actual admin, most pages just present you with a RTE field and a few other settings, but through the customizer, developers can define ‘sections’ with their own fields or repeatable blocks to allow merchants to customize complex content and layout on their pages.

Don’t get me wrong, I adore sections and the addition of them has been the single greatest addition to Shopify since I started working with the platform. The downside is that for now, only homepage sections can be added and reordered. Other pages must have their sections predefined and placed in order within the template code. Even more frustrating is that while sections on the homepage are unique, sections on other pages are shared. So while you may be able to have multiple instances of say, a hero image component on the homepage, if you wanted to have hero components on a ‘Contact Us’ and ‘About Page’ with different content, you would need to define separate sections for this. There are different techniques to work with this limitation, but all involve duplication of the schema, and it requires developer intervention for the creation of new customized pages, even if it’s only to copy and paste sections to create new instances. Allowing the full use of sections on all pages would open up a ton of new interesting possibilities for designs without having to do anything hacky like processing the RTE output or adding shortcodes.

Additional section features

In addition to rolling out sections for all pages, it would be fantastic to be able to define some additional settings for sections, like what pages they can be added to. A list of product features might not make sense on non product pages, but it would still be nice to have it as a section so it can be reordered on the product page. It would also be useful to be able to define whether or not a section’s content is ‘global’ or not. For example, you may have a list of products currently on sale on some pages in your store. In this case, it wouldn’t make sense to have it be a part of your layout files, but you might want the content of that section to be the same any time it is used, and if it is updated on one page, it would be updated on all pages that it is present on.

Redesign the Image Picker

While I’m on the topic of the the customizer, I think the image picker could use a redesign. I understand the desire to show the content being edited next to the images, but whenever I need to reuse an older image, the small image panel isn’t much help. A search bar would go a long way in helping to track down existing images, and it would be even better if there was an option to look through past images in an expandable window, as seems a bit ridiculous to me that on my large external monitor, I can only see 9 thumbnails at a time. I often see editors re-upload the same image to save themselves the trouble of trying to find an older image, which means customers don’t get the performance benefits of things like caching.

SVG Uploads

My team have heard me say this enough, but Shopify, it’s 2019, please give us SVG upload support in the image picker! Vector-based illustrations and icons are a huge trend that is not going away any time soon, and it would be nice to allow people to upload crispy logos.

Option to force alt text

One final thing I would like for the image picker is the ability to force an image to have alt text added before it can be saved. I look forward to a day where we can leave image carousels in the past, but until we reach a point where clients stop putting critical information exclusively in images, we need processes to ensure that we are not leaving screen reader users out of the equation. Right now, adding alt text is very much optional and it can be easily forgotten by a site editor.

First Party metafields support

Ask any Wordpress developer what their favorite plugins are, and you’ll find that Advanced Custom Fields is near the top of the list. ACF is a fantastic plugin that lets a developer add fields directly to the admin panel, allowing editors to edit complicated page layouts without fiddling with HTML or page builder plugins. Shopify’s answer to this is ‘metafields’ — nearly all Shopify objects let you assign metafields to them. Metafields are often used by apps to extend Shopify’s features, but they can also be used to populate unique content for specific products, pages, etc. For example, if you wanted to add an instructional video to your product pages, you could define a metafield for the embed code, and pull it in on the product templates.

The downside with Shopify is that there is no way to pull in metafields directly into the admin pages, you must use an external app. Because of the necessary authentication steps required for an external app, editing metafields can be a time consuming and annoying process. Some apps only let you edit the metafields that were created within that same app, which ties you to that particular app, but apps that show all metafields can show information that is unnecessary for the editor, like configuration objects for other app functions. Having the ability to define metafields that can be shown directly within the admin panel with a corresponding field type would significantly improve the editing experience for merchants.

Improved Git workflow

One thing I enjoy about Shopify is the way they approach configuration. A store’s settings (everything from what colors are used to the content for the sections) is stored in a single config/settings_data.json file, which makes migration and backups easier as you don’t need to keep track of a local and remote database. It’s treated as any other file, which means that you can edit locally and have ThemeKit sync up your changes remotely, or pull down remote changes from the live store whenever needed. However, when it comes to keeping track of this file in Git and managing it within the context of an active store, we’ve hit several barriers that make this a lot more unwieldy than we’d like.

Much of Shopify’s theme tooling has been built around the use case of building a theme that would be used by many stores or sold in the theme store. In cases like this, the developers can easily manage the theme. They do not need to be concerned with a specific store’s configuration, and they can treat their repository as a single source of truth and push updates to the theme store.

In the case where a developer is actively maintaining an existing store, managing version control becomes a lot more difficult. Most developers will have a seperate theme that is forked from the currently live theme where they will be implementing new features. To track this in Git, you might have the master branch correspond to the currently live theme, and new feature branches being created to correspond to themes that are not currently live but can be previewed through the admin. While a developer is working on a new feature, the merchant may install and configure a bunch of new apps that directly modify the theme code, and rearrange the homepage sections to reflect a new promotion. The developer needs to be actively pulling all these new changes into Git, or they might be lost when the feature branches are merged. Even worse, a developer may actively be trying to stay on top of these changes, but still potentially lose client content when it comes to merging due to the way JSON works.

Below is a abridged snippet of code that demonstrates how Shopify stores data for content blocks within the config/settings_data.json file. The numbers represent longer IDs that have been cut short for demonstration purposes, and each block represents a slide in a carousel.

"1": {
  "type": "carousel",
  "blocks": {
    "1": {
      ...
    },
    "2": {
      ...
    }
  },
  "block_order": [
    "1",
    "2"
  ],
}

As you can see, they are using a JavaScript Object for the block settings, and a separate block_order Array to determine the what order the blocks come in. We recently had a case where the client added a slide to the homepage while we were working on a separate feature branch. When it came time to merge feature branch with the master branch, the JavaScript object with the blocks was reordered as there is no guaranteed order on key/value pairs. As a result, the merge ended up creating an invalid configuration object with two duplicate slides and we ended up ‘losing’ a slide.

Most developers (and Shopify themselves) utilize the approach of completely ignoring the config/settings_data.json file in Git to avoid these hassles. This approach works if you are not servicing any particular store in general and are just developing themes, or if you are managing a store which lacks complex custom features and does not need to be updated often. But for large active stores, particularly Shopify Plus stores, better support for things like version control and workflow tooling are necessary to prevent potentially costly mistakes in the form of broken deployments and data loss. I’ve often encountered stores where developers are working directly on the live theme with no version control whatsoever, which can lead to disastrous consequences for the merchant. Improving the developer experience would allow developers to provide better service to merchants, and cultivate a healthier developer ecosystem around the Shopify platform in general.

Highlight accessible themes and apps

Shopify has made great strides in improving accessibility in recent years, and I am very glad that they have a team devoted to working on improving the accessibility of their platform and their official themes. Currently, Debut and the Shopify Checkout paired together make for an experience that has been well tested by their accessibility team, so if it is a hard requirement that your store complies with the WCAG 2.1 guidelines, the Debut theme is a great place to start. Shopify also has a library of liquid snippets that serve as a great reference for anyone looking to implement common e-commerce patterns in a semantic and accessible way.

Shopify’s commitment to writing accessible code is great, but for now, third-party themes and apps remain a completely different ball game. The Shopify team have expressed that they are working on a set of guidelines for themes and apps to adhere to, and while I am very excited for this possibility, there’s not much out there right now to help well-meaning merchants find an accessible theme. Apps can be especially problematic, as a fairly accessible experience can be rendered completely inaccessible by something like a poorly-written email capture modal that offers no way to close it through keyboard access alone.

During the transition period for between now and whenever the accessibility guidelines are rolled out, it would be great to see functionality that would highlight more accessible themes and plugins within their respective stores, such as a special tag or something along those lines. Adding something like this would encourage theme developers to make accessibility a priority now, rather than waiting till when the guidelines come out and doing the bare minimum to meet them. Many merchants these days are more concerned about accessibility (even if only to avoid a facing a lawsuit), but right now, they lack the ability to make decisions about it without the guidance of an experienced technical person.

Closing Remarks

I hope that what you take from this article isn’t ‘Shopify is a crappy platform that needs a ton of fixes to be usable’. On the contrary, I think Shopify is a great platform that has continued to implement features to improve both the developer and merchant experience. I would like nothing more than to have solutions to all these problems announced at this year’s Shopify Unite conference so as developers, we can better meet the needs of not only our clients, but their customers as well.

If you’re also a Shopify dev, I’d love to hear from you! What features would you like Shopify to implement?

General

Right off the bat, I knew the color scheme was probably going to fail. While the body text, a deep navy, would definitely pass, I had some places where I knew the color contrast was too low, and my project pages had small transparent white text against a brand color that may or may not have been chosen with contrast in mind. Using this fabulous tool, aremycolorsaccessible.com, I was able to input colors from my color scheme, and play with the toggles to find accessible alternatives and combinations. This tool is great because it not only tells you if your chosen colors are accessible, it also lets you go and tweak the color scheme directly on the same page, so you don’t have to go back and forth between your graphics software and the browser.

Take Home Message: Color schemes and contrast play a significant role in determining whether or not a site is accessible. Tooling can be extremely helpful for determining appropriate color schemes.

Navigation

One easy accessibility win is adding a ‘Skip to Main Content’ link. This is a link which targets the main element on the page, allowing keyboard users to easily bypass tabbing through the whole navigation on each page. Most modern screen readers are smart enough to allow you to skip navigation elements if they are properly marked up, but this is still a nice thing to have for sighted keyboard users.

I ended up giving a solid background to my navigation on all pages (as opposed to a transparent background), so that I would eliminate the possibility that I’d choose a background that provided too little contrast for my navigation links. I also made sure that aria-current="page" was added to the currently active navigation link. In addition, the existing hover and focus state of my navigation items needed improvement, as the current focus state relied solely on a color change. It is best not to rely exclusively on changing color in order to convey important information to the user, as certain types of color blindness can prevent people from easily detecting the change. I added an underline to the ensure that the currently highlighted nav item would not be missed.

Take Home Message: Navigation is a crucial component to get right. Opt for visible navigation over hidden navigation if possible, and do your best to ensure that you can use the keyboard to navigate the menu by using clear focus states and appropriate elements and aria-roles when applicable.

Homepage

I had taken the time to ensure that the homepage, with it’s fancy scroll effect and all, still worked without JavaScript enabled. For sites with fancy animation where the elements load in on page scroll, it’s common to set the initial state of elements to be animated with CSS, and then apply the transition with JS once the user has scrolled down to that section of the page. Because these transitions often involve transitioning from 0 opacity or transitioning elements from off the page, it’s a good idea to set some kind of fallback method so that in case JS fails to load for some reason, your users can still interact with the page.

While I had progressively enhanced the whole layout, I had missed some basic semantics in the markup that would make a big difference to the experience of screen reader users. For example, look at the code snippet below:

<div class="tags__wrapper">
	<span class="tags__tag">Jekyll</span>
	<span class="tags__tag">Forestry</span>
	<span class="tags__tag">SCSS</span>
	<span class="tags__tag">Javascript</span>
</div>

Spot the issue? We should probably list these items out as an unordered list instead. Newer developers will often reach for the markup that is easier to style instead of choosing the element that is the most semantic, and this has a tendency to hurt not only screen readers, but any kind of robot/crawler, including search engines. Using semantic elements for list elements can allow screen readers to say the the total number of elements and allow for easy navigation within the list elements, and it is worth it to take the time to do a little bit of extra styling in order to make sure that the elements are read correctly when read aloud by screen readers.

One more thing to note about the homepage - consider the markup below:

<a class="button button--small" href="/projects/studio-ryte">
	Read Case Study →
</a>

Links that say things like ‘Read More’ or ‘Learn More’ are quite commonly seen across the web, but they can hurt scanability. Some screen readers offer the functionality of listing all links on a page. Vague link text or repeated link text can be confusing for users trying to scan for the link they want to navigate to when out of regular document context. Complicating things further, the title attribute is handled inconsistently between screen readers - some will ignore it completely and some read both the link text and the title attribute. We can provide context for screen reader users by adding screen reader text to the link, a trick I picked up from Lindsey Kopacz’s excellent blog! The corrected markup is as follows.

<a class="button button--small" href="/projects/studio-ryte">
	Read <span class="screenreader">Studio Ryte</span> Case Study →
</a>

Take Home Message: While the end result may all look the same to a sighted user, proper semantic markup gives you a ton of accessibility features for free. Consider the desired experience for your users and use the appropriate element based on that, not based on what is easiest to style.

About Page

The about page features a resume section in addition to a contact form. Below is a sample of some of the resume markup in Liquid.

<h2 class="resume__heading">Resume</h2>
<h2 class="subheading">Related Experience</h2>
{% for exp in page.experience %}
  <span class="resume__institution">{{ exp.institution }}</span>
  <span class="resume__title"> {{ exp.title }}</span>
  <span class="resume__bullet">&bull;</span>
  <span class="resume__date">{{ exp.date }}</span>
  <ul class="resume__description">
    {% for desc in exp.description %}
      <li>{{ desc.li }}</li>
    {% endfor %}
  </ul>
{% endfor %}

Right off the bat, we can see that I used two H2 tags in a row. ‘Related Experience’ is most definitely supposed to be a heading under ‘Resume’, and the two have separate classes with different styling to distinguish them visually, so the only cause I can think of is that I must have been copy and pasting from other parts of the project without really thinking about what heading level was appropriate in the context of the destination. 🤦

Screen readers allow users to navigate by heading levels, so having a clear document structure is necessary. With the markup above, it would appear that ‘Resume’ is a completely empty section to a screen reader user! We can fix this up by making ‘Related Experience’ an h3, and further improve readability by putting the position title, instution and date in a h4 to mark it as a heading before the list element below it.

<h2 class="resume__heading">Resume</h2>
<h3 class="subheading">Related Experience</h3>
{% for exp in page.experience %}
  <h4 class="resume__point">
    <span class="resume__institution">{{ exp.institution }}</span>
    <span class="resume__title"> {{ exp.title }}</span>
    <span class="resume__bullet">&bull;</span>
    <span class="resume__date">{{ exp.date }}</span>
  </h4>
  <ul class="resume__description">
    {% for desc in exp.description %}
      <li>{{ desc.li }}</li>
    {% endfor %}
  </ul>
{% endfor %}

Take Home Message: Proper use of headings is essential for screen readers. Always evaluate what heading level is appropriate in the context of the resulting page. Be especially careful when using frameworks/component libraries that may abstract over the generated markup, it’s easy to reach for the element that matches the design and not realize that you are using an incorrect heading level.

Illustrations

The illustration section of my portfolio site is fairly simple in theory. Because the order of illustrations doesn’t matter in this case, I have chosen to use CSS Multi-Column layout to create a Masonry style effect without loading any additional JS. Upon clicking an image, the image will open a modal that shows the full image and the title.

The modal was powered by Lokesh Dhakar’s Lightbox 2 script, originally written over 8 years ago. The script used JavaScript to handle things that were difficult to do with CSS during that time period, like controlling the sizing and positioning of the image, and was ridiculously simple to set up. However, I realized the script failed on some basic accessibility issues, such as lacking alt text support, and failing to trap focus within the modal. An accessible modal should not only transfer focus to the modal when opened, it should also hide all other content to screen readers, and it needs to keep focus within itself until the element is closed. Otherwise, you can encounter an unpleasant situation where you can tab out of the modal, but the modal remains open, obscuring a keyboard user’s current position on the page. I did some research by looking through the project’s Github issues, but it seemed like accessibility fixes weren’t a priority for this version of the project, and would be better handled in version 3.

I decided that instead of submitting a PR to a project that wasn’t actively being worked on anymore, I would find a new tool that would help me replicate the lightbox functionality. Additionally, I could kill two birds with one stone and take steps to remove my site’s dependency on jQuery. Honestly, finding component libraries that are explicitly focused on accessibility and aren’t tied to some other JS framework, whether it be jQuery, React, or something else, can be quite difficult. I find myself returning to Heydon Pickering’s Inclusive Components and Scott O’Hara’s Accessible Components time and time again whenever I need to find good examples of common UI patterns.

In this situation, I ended up using the a11y-dialog library. I’ve used this library successfully on several client projects, and it exposes events that I need to dynamically generate the necessary markup. I like this library in particular because it comes with no styling - not a perk for most people, but this is great for projects when you need to match a client’s designs and you don’t want to spend hours overriding the highly specific CSS that often comes with these libraries! It uses the native <dialog> when the browser supports that element, and makes it work on older browsers that don’t support <dialog> just yet.

I won’t go into too much detail about my implementation, but there are a few things that are worth noting. I kept the modal trigger element as links to the larger versions of the images instead of a button, I like this as a form of progressive enhancement - if for some reason the JS fails, you can still see a larger version of the image by clicking on the link. I used flexbox on the contents of the dialog window, so that the title could be before the image in the source order, allowing the image to fall under the heading (a trick I picked up from Heydon’s article about cards!). I then used the order property to visually move the title below the image, as is more conventional when displaying art, so both sighted and screen reader users will experience a structure they are more familiar with. Using flexbox and the :not(:empty) selector allowed me to easily conditionally resize the image to occupy the full height if there wasn’t a title (naming things is hard, as we all know). You can visit this commit on Github to check out the code for the dialog.

Take Home Message: A single inaccessible dependency can render a site impossible to use for screen readers. Audit any UI libraries thoroughly before incorporating them into your project!

In Closing

I hope this post has been somewhat helpful! Lately I have seen a greater push for web accessibility, and I wanted to contribute something that would provide a little more detail to those who already understand why accessibility is important, but are unsure how to begin implementing it. I’d like to close with some resources which have been incredibly valuable to me in my learning process:

• Inclusive Components by Heydon Pickering
• A11y with Lindsey
• Everything by Scott O’Hara
• The writings of Adrian Roselli
• Video of Léonie Watson using various websites with a screen reader

Canvas Basics

The canvas API is fairly primitive in that once you draw a shape, you can’t really go back and edit it. This is the exact opposite of CSS or Javascript animation frameworks like GSAP, where you can reach in and grab a particular element with the targeted use of selectors. Because of this, the typical animation flow goes something like this:

1. Clear the canvas
2. Draw the canvas elements
3. Modify the elements that are to be animated
4. Grab the next frame, typically with requestAnimationFrame

It’s pretty amazing to think that with every frame of this animation, we’re drawing the same lines over again, eh? MDN was an invaluable source for me when I was trying to understand this process.

On Algorithmic Perfection

I spent a lot of time trying to come up with the perfect formulas for calculating things like opacity, speed, and scaling. If we were modelling a real life situation, getting an accurate algorithm would be top priority, but since we are merely using these functions to generate a visual representation, there is a lot more freedom! Getting something that just ‘feels right’ is perfectly acceptable, and in some cases, preferred, over trying to manually calculate that perfect bezier curve.

On Persistence

I admit I’m a little ashamed to post this, but above is my first attempt at trying to generate a pattern of network lines with Javascript. It wasn’t even in the same ballpark as what we needed, and I used exactly none of the code in the final product. Regardless, it’s an important reminder that experimentation is necessary - you will probably fail your first few attempts when attempting a new thing, and that’s perfectly normal.

Preparing a bootable version of Linux

Before we begin, it’s advisable to prepare a backup version of Windows, especially if you have any data on there that might be of value. Because I was using a brand new machine and I live on the edge (not the Microsoft Edge, geddit?), I chose to forgo this step.

You will need a clean USB with at least 4GB of space. I first grabbed Ubuntu 16.04.01 from the official Ubuntu Website. I then downloaded Rufus as recommended in their docs to format the USB. Ubuntu has prepared an excellent guide on how to do this, but basically you are selecting your USB stick and your freshly downloaded Ubuntu installation and writing it in ISO mode.

Enabling AHCI Mode on your SSD

Since my machine came with Windows 10 preinstalled, I needed to adjust the SSD configuration as Ubuntu wouldn’t recognize the hard drive in RAID mode.

Following this discussion thread, I ran the following steps:

1. Search for command prompt, right click and hit Run as Administrator
2. Type the following to force a safe mode boot bcdedit /set {current} safeboot minimal
3. Restart your machine, and hit F12 on the Dell screen to pull up boot options
4. Select Bios Setup
5. Expand System Configuration and select SATA operation
6. Switch from RAID on to AHCI
7. Save and exit to boot into Windows 10 Safe mode
8. Run command prompt as administrator again
9. Type bcdedit /deletevalue {current} safeboot to disable safe mode boot
10. Restart your computer again. Success!

Creating space for Ubuntu

Alright, time to shrink down our windows partition to make space for Linux!

1. Search for Disk Management (or open Command Prompt and type diskmgmt.msc)
2. Identify the disk with your Windows installation. For me, it was the one that was 400GB+.
3. Right click and select Shrink Volume
4. Shrink it by your desired amount. I originally opted for 40GB (or 40,000MB), but I found that for what I was doing with Linux (React Native and Android Emulation), I needed more, so I eventually expanded it to 70GB
5. You should see the unallocated space show up!

Installing Ubuntu

Alright, it’s show time! Plug your bootable Ubuntu USB in, restart your computer once more, hit F12 and choose to Install Ubuntu from your USB. The installation process is fairly simple, you can follow Ubuntu’s Official Guide. Because we are dual booting, I chose to install it alongside Windows boot manager. Now that we’ve unallocated some space for Ubuntu and switched to AHCI mode, it should recognize the unallocated space as an option and install it to that space. Whew! The hard part is over.

Fixing the Touchpad

The first thing I noticed on my new Ubuntu install was that the trackpad didn’t have palm detection turned on, and it was making typing a nightmare. To resolve it, I installed Libinput and configured it with the following steps:

1. Open Terminal, type sudo apt-get install xserver-xorg-input-libinput
2. Edit the config file by typing gedit /usr/share/X11/xorg.conf.d/90-libinput.conf(or vi if you prefer vim). It may be located in a different location depending on your Ubuntu installation.
3. Scroll down and modify the Touchpad input class like so:

Section "InputClass"
    Identifier "libinput touchpad catchall"
    MatchIsTouchpad "on"
    MatchDevicePath "/dev/input/event*"
    Driver "libinput"
    Option "Tapping" "True"
    Option "PalmDetection" "True"
    Option "TappingDragLock" "True"
EndSection

Phew! Now we can finally type without wanting to pull our own hair out.

Fixing the Time Zone Issue

What? We’re still not done? :( There’s one more thing we need to fix before we log back into Windows again. There tends to be conflicts with how the time is stored when running Windows and Linux on the same machine. Luckily, it’s an easy fix if you want to run Linux on local time as opposed to UTC. On our version of Ubuntu, simply open up the terminal and type timedatectl set-local-rtc 1. The Ubuntu Website offers alternative solutions if you prefer.

Now we’re finally done. Happy developing!

The Details

Since we are unable to transition between gradients using CSS, some trickery was required. For the animated bar part, I set the background to a linear gradient between 3 colors, then sizing up the background to 200% in width, but 100% in height. To achieve the effect of a gradient transitioning, I transformed the background position back and forth.

The little nodes on the end of the divider are nothing special, simple pseudo-elements, but they certainly add to the network theme of the site, don’t you think?

See the Pen Animated Dividers by Nic Chan (@nchan0154) on CodePen.

Setting up a development environment

Because Shopify doesn’t let you download their software, what I recommend doing is signing up for a Partner Account, which lets you create unlimited test stores (as well as pick up a percentage of profits if you refer customers to the platform). Rather than manually upload your theme files to your test store every time, you can either use the Shopify Theme Gem or the Mac Only Desktop Theme Editor to sync all your theme code directly to the test store. I chose the gem - the set up instructions included in the repository were very straightforward and it didn’t take long before I was up and running.

Picking a starter theme

Once your theme watch is up and running, you can choose to go with an existing Shopify starter theme to help speed up your development process. Skeleton is the more minimal of Shopify’s two official themes, with the bare minimum amount of boilerplate to get you started. Timber is the one I ended up using, it includes a helper class based grid system, an AJAX based interactive cart and responsive menus. If you’d prefer to roll with the more popular Foundation or Bootstrap, it might be wiser to go with the skeleton theme.

A shopify theme has the following folders:

• assets
• config
• layout
• locales
• snippets
• templates

If you poke around the assets folder, you might notice that all the styling is done in one giant .scss.liquid file, which Shopify compiles on its own servers. If you’re used to a modern, modularized CSS workflow, the ban against @import will seem like a nightmare. Running your own SCSS processor and uploading the compiled CSS is an option, but doing so won’t let you use liquid variables (aka Shopify settings you might want to include like colors and font sizes) within your SCSS. What I ended up doing was running a gulp task that watched a newly created scss folder. Upon detecting changes to the contents of that folder, it would use gulp-cssimport to string my stylesheets together into one giant .scss.liquid file that it then dumped into the assets directory. Below is my Gulpfile.

var gulp = require("gulp");
var cssimport = require("gulp-cssimport");

var globalConfig = {
	src: "scss", // The directory where all your SCSS is
};

// Process CSS
gulp.task("styles", function () {
	return gulp
		.src(globalConfig.src + "/style.scss.liquid")
		.pipe(cssimport())
		.pipe(gulp.dest("assets/"));
});

// Watch files
gulp.task("watch", function () {
	gulp.watch(globalConfig.src + "/**/*.*", ["styles"]);
});

// Default task
gulp.task("default", ["watch"]);

And my style.scss.liquid looked something like this:

@import url('_variables.scss.liquid');

@import url('libs/_timber.scss.liquid');
...

@import url('components/_header.scss.liquid');
...

This way, you get to structure your scss however you are used to doing it. Crisis averted!

Creating your own settings

Those of you coming from Wordpress will be pleased to know that adding new settings to Shopify is as easy as changing the config/settings_schema.json file. Below is a snippet from mine.

{
	"name": "Colors",
	"settings": [
		{
			"type": "header",
			"content": "TNB Theme Colors"
		},
		{
			"type": "color",
			"id": "tnb_color_bg",
			"label": "Background Color",
			"default": "#222222",
			"info": "Background color"
		}
	]
}

This setting can be accessed in your .scss.liquid files just as easily, like so {% raw %}{{settings.tnb_color_bg}}{% endraw %} .

Final observations

While I found developing for Shopify to be a breath of fresh air compared to working with Wordpress (figuring out how to handle theme settings + SCSS in Wordpress is just plain shitty), I have a few caveats. Shopify doesn’t let you customize the checkout.liquid template (the template that handles the checkout process) unless you are a Shopify Plus customer. It also doesn’t make it particularly easy to filter by product variants, which is the standard way to assign things like colors and sizes to a product. Those who might want complete control over the entire user experience or offer complicated product filtering without resorting to workarounds like manually managing tags should seek out a more robust platform, but if ease to use is a priority, I definitely wholeheartedly recommend Shopify.