New Blog

Hi folks. I’ve started a new blog over at https://vcolavin.com/blog. This current WordPress blog will be around indefinitely as an archive.

Leave a comment

Filed under Uncategorized

Portfolio

Hi there. I haven’t written a portfolio on my main website, so here’s a stand-in.

The Nature of the Beast

See it live at https://vcolavin.com/nature-of-the-beast
See the code at https://github.com/vcolavin/nature-of-the-beast
Technologies: TypeScript, React, Redux, Scss, Webpack
2018 – 2019

I work full-time, so I don’t do a lot of open-source work in my spare time. Sometimes, though, the spirit moves me and I put a few hours into my main active project. It’s still evolving, but right now it’s an interactive fiction inspired by 80s text-based adventure and the terminal console. In a word, it is nerdy. In more words, it’s nerdy and strange and literary and deeply personal.

Salmon Explorer

See it live at http://salmonexplorer.ca/
This project is close-source.
Technology: TypeScript, React, Redux, Mapbox, Scss
2018

An app to look at huge amounts of data about fish in the Pacific Northwest! I worked on features all across this app, but I was entirely responsible for the on-demand PDF generation. Warning, some PDFs are very data heavy and may take a long while to load.

Lumina Stronger Nation

See it live at http://strongernation.luminafoundation.org/report/2019/
This project is close-source.
Technology: React, Redux, TypeScript, Nivo.
2018 – 2019

A way of finding information about higher education attainment rates in the United States.

I also built the entire Predictive Tool, which at this moment is hidden behind that “coming soon” button. It’s really cool, I promise.

Animal Wellness Action Website and Congressional Accountability Tool (CAT)

See it live at https://animalwellnessaction.org/
This project is close-source.
Technology: React, Redux, TypeScript, WordPress, Jupyter Notebooks (for data ingestion).

The coolest part of this suite of sites for AWA is the CAT: https://cat.animalwellnessaction.org/. However, I built the blog using good old-fashioned WordPress. I learned it from scratch in a couple of weeks, and had a lot of fun building the custom theme.

Leave a comment

Filed under Uncategorized

Using ARIA roles and background-image

Here’s something I just learned about, so I’ll make a note here so I can remember it for later.

Here’s the main source: https://fae.disability.illinois.edu/rulesets/IMAGE_1/

Often, when adding an image to a web site, I need to have particular control over the images behavior. These needs lead me to use a div with a CSS background-image property, rather than an img.

This is great because it gives access to many powerful formatting rules, like background-cover and background-clip. Unfortunately, it also lowers accessibility. Screenreaders assume that background images are ignorable and decorative.

Here’s how you can fix that. Give the div the ARIA-role of img, and alt text, like this:

<div role="img" alt="description of the background image" />

And that’s it!

I’m using JSX and TypeScript, and TypeScript doesn’t expect a div to have an alt attribute, but as far as I can tell it’s perfectly valid and necessary HTML. You’ve just got to extend the types.

Leave a comment

Filed under Uncategorized

Fighting Ableism by Improving Accessibility in Technology

Or, The Why and the What of Accessibility.

I’ve written this article after a conversation about accessibility (aka a11y) with a friend who is a relatively new programmer. So that’s the general audience. You don’t need to know how to program to get the gist of this article, but at some points it might be helpful. There’s also prior art to all of this. I’m just adding a voice to my side.

As a non-disabled person, I cannot pretend to fully grapple with or understand the immensity of ableism or its myriad and complex intersections with capitalism, patriarchy, and white supremacy. I cannot solve it on my own. I build dorky little web apps. But here is what I can do: I can respect and believe the experiences of disabled people. I can build web apps that as many people as possible can use, and I can encourage my clients and peers to do the same. I can advocate for codification and stronger enforcement of accessibility standards.

Neither I, nor any other single person, nor any app, can on their or its own dismantle ableism. But I want you to take this idea for granted: If you are designing or building something and not considering how disabled people might interact with it, you are actively taking part in their oppression. Instead, I want to encourage you to question, fight, advocate, and build.

Specifically, when you build something and imagine the user, do better. Question critically, how would a blind person use this? Are the colors you’ve chosen in this graph usable by a person with colorblindness? What if someone lacks fine motor control, can they use the keyboard to navigate?

If you don’t ask and answer these questions, you are implicitly and actively, if accidentally, excluding these people. You will find, I hope, that these questions are deeply challenging and exciting and fun and rewarding; disabled people are a wildly diverse group, and the ways the interact with technology are equally diverse. Despite this, there are a few simple things you can do to dramatically widen the accessibility of your work.

It is past time to learn, but learn now. Instead of, or in addition to, thinking about how Uber for Dogs is going to improve the world, do the good work to make the world better.

Two anecdotes about resistance to accessibility in tech

If you’re already convinced on the “why”, skip ahead to the next section to read a brief primer on the “what”. Here are two personal anecdotes about the barriers to building accessible apps.

If you’re a programmer or designer, you’ve probably experienced how little time, attention, and money is given to the subject of accessibility. Business interests are orthogonal at best to the interests of humanity.

For example, at my last job, I advocated for increasing the use of Semantic HTML and ARIA Roles in a particular web app; these techniques make it easier for screenreader software to traverse the page and read it coherently. My boss told me not to spend time on it, because we had no blind users. The question of why we had no blind users didn’t occur to them. We had a greater proportion of users using an ancient version of Internet Explorer, so we spent our energy supporting them instead.

That was a story of a depressingly lazy self-fulfilling prophecy. The business thus became an anti-human cult narrowly obsessed with Internet Explorer 8. Note that I don’t think that supporting IE users is the problem here.

Here’s another story: I was working on solving a problem having to do with tab focus and browser history in React. The UI worked fine when using the mouse, but degraded severely when using keyboard navigation. My boss told me to stop working on it; not because of time constraints, but because he was concerned that I would degrade the user experience for mouse-users in my quest to make it usable for keyboard users.

That was a story of how ableism had tricked my boss into thinking that access to our work was a zero-sum game; that for one group to win, another had to lose.

What to do better

The good news is that modern browsers and operating systems are, by default, magical vortices of accessibility. They have built-in keyboard navigation, and they offer tools for zooming in, increasing contrast, and reading content out loud.

The bad news is that a modern developer’s job is often to pave over that magic with JavaScript.

In practice, most accessibility work is simply re-enabling the built-in tools that we’ve paved over.

Here is a personal codification of the things I consider when building an app. I’m avoiding descriptions of implementation details, but if you find a glaring omission or fallacy, please let me know.

An accessible site or app

  • has text which is legible, e.g. sufficiently large and high-contrast;
  • does not rely solely on color to indicate important information;
  • remains legible when zoomed up to 200%;
  • is keyboard-navigable;
  • plays nice with screenreader software like JAWS or Voiceover;
  • works even when JavaScript and CSS are disabled, aka progressive enhancement or at least graceful degradation.

Some related ideas that are less commonly considered under umbrella of accessibility are that a site or app should:

  • remain usable over a 2G or satellite connection;
  • remain usable over a wide range of viewport sizes, aka responsive;
  • not require the user to learn novel rules and systems;
  • not subject the user to potentially triggering content without warning.

Although these last ideas aren’t related to widening access to technology to disabled people, they widen access in general. People who rely on satellite internet or 2G connections have a right to take part in technology. People whose only computer is a smartphone have a right to use our products. I would argue that there are few valid technical reasons why not.

There are difficult edge cases where it’s not clear what best practices are. How can a JavaScript-dependent single-page app degrade gracefully? How should an inherently visual product be presented to a screenreader?

For that last question, I am thinking specifically of interactive data visualizations, which is what I specialize in at Periscopic. These are difficult questions without obvious answers, but that’s what makes them so engaging. Let’s figure it out.

Leave a comment

Filed under Accessibility, code

I’m gonna go into that Dragon Ball Z trainingroom where gravity is like 100 times stronger and time slows down and I will become extremely powerful

I will become extremely powerful and noone will be able to stop me.

Leave a comment

Filed under Uncategorized