I’ve been experimenting. I’ve been concocting a recipe for vegan kugel, and rediscovering little features and edges of my website I’d forgotten I baked in. Like chocolate chips hidden in an oatmeal raisin cookie.
One chip most recently re-discovered: support for per-page custom styles?! All I gotta do is include an optional bit of meta data, bespoke-css, that points to a style sheet. I may play with this feature more. I do love myself some css. I can tell exactly when in my life I added this feature because these days I’d never call such a thing “bespoke-css” — it would get a much more boring, terse label, like “css” or “styles.”
The kids have been home on school break this week. We’ve been having a lot of fun reading The Wind in the Willows aloud, and playing a bit of No Man’s Sky on creative mode. You wouldn’t think it, but each carry a really similar vibe. Cosmic-pastoral-localism?
In the last week notes I made mention of potty training; at first that was harrowing and seemed like it would never happen. Then, all at once, it did!
I continue to expand the newly formed wiki. My plan isn’t to catalogue everything and anything — outboard brain style — but to really only document stuff I find useful and that I want to keep track of for myself…that maybe will be useful for other folks, too? The acme page is probably most inline with what I’m going for.
For good times, check out ratfactor’s rad presentation on forth!
I’ve also been playing with babashka, reading it’s excellent companion book, babooka. Babashka is a wicked fast way to use clojure when you’d normally reach for bash.
In accessibility and the product person I said
we need to make accessibility a core part of our processes
Here, I want to talk about that in more detail. I want to briefly explore what making accessibility a part of core processes looks like, and how that is different from centering accessibility as a priority.
RICE is a scoring model many organizations use to prioritize what to focus on. If you aren’t familiar with it, RICE is an acronym that stands for reach, impact, confidence, and effort. The idea is that you assign a point value to each facet, and use the sum of those points to help determine priority between a few competing ideas.
If accessibility isn’t part of your core processes and baked into the culture of your work it will show up as one of many competing ideas all placed against each other in the RICE model. When pitted against other ideas, and when using tools like RICE, accessibility, and equity concerns writ-large, are gonna loose. They’ll be considered, discussed, added to the backlog, but, almost never prioritized. They won’t be prioritized because, across the software development landscape, accessibility isn’t a profit center, it is a cost driver.
But this is a solvable problem.
Stop using RICE and tools like it that don’t include accessibility and equity as facets of their model.
Add it if it isn’t there.
By adding them as a facet, RICE+Equity, you make accessibility a key part of all your decisions. You can still put the accessibility projects up against other ideas, but no matter what, by baking accessibility (and equity, generally) into the frameworks used to determine priority we can begin to ensure accessibility is a core consideration helping to guide all product decisions, and not left as a project on the backlog.
I recently re-read Peter Naur’s “Programming as theory building”. Afterwards I set out to write my own text editor. The paper posits that it’s really hard, if not impossible, to fully communicate about a program and sort of gestures at the futility of documentation…what spun around inside my head as I read was that our primary programming medium — text files — is silly. Like, some folks would totally 100% scoff at my writing forth but, at the end of the day, forth and javascript both produce executable text files despite being lightyears apart. What if a text editor let us have something more than just text files as artifact?
So, like many before me, I started to write my own text editor. And it sucked. What I made sucked, and the process itself sucked…or, at least, it didn’t lead to anything particularly different from the vast array of existing text editors. I wanted to be able to support a different paradigm of writing code, I didn’t wanna just produce vim with worse ergonomics. I didn’t make much progress, even leveraging web technologies that gave me a lot “for free,” because before I could begin to reinvent any particular wheel I had to crawl out of the primordial ooze…
Then I realized I didn’t actually want to implement my own text editor! I’m not a fanatic about what editor I use; I’m pretty evenly split between sublime text, emacs, text edit, vim, acme, and mg. I bounce between them depending on what I’m doing, and for how long I’ll be doing it. What I wanted was to be able to support a slightly different mental model of what a “file” is using any existing editor!
That was an easier technical nut to crack. It took about 2 hours after the kids went to bed with a little bit of help from the inimitable llimllib on mastodon…and all I did was write a shell script!?
So, my personal solution to the cutting edge of programming being just text files is to add even more text files!…at the end of the day, they’re a really really hard thing to leave behind, especially if you’d like to preserve compatibility with any existing programming system.
I wrote a shell script called Moon Maker. Moon maker, or mm, lets you attach orbiting moon files to central planet files. A planet file is the one you really actually care about — its probably a file in a project. A project can have any number of planet files, and a planet file can have any number of moons in orbit of it. Moons are files that orbit a planet, they’re places to take notes, a scratch space, somewhere to try things out, or add layers of information about the planet. A moon file can have any file extension, and references the planet by it’s name. Moon files live in a directory of their own, .moons, and each can be referenced by a unique id, or, collectively by the name of the planet they orbit.
Moon Maker
⋆｡°✩ ☾
mm is a small program that lets you add orbiting moons to existing planets.
A planet file is the one you care about -- probably a file in an actual project.
Moon files orbit planets, they are disposable scratch spaces connected to planets.
usage: ./mm
-i(nit)....initialize a directory to store moon files
-o(pen)....open a planet file and all of its moon files
-l(ist)....list all moons for a given planet file
-a(dd).....create a new moon file for a given planet file
-d(elete)..remove a moon file by its id
-c(lear)...remove all moon files for a given planet file
-u(pdate)..rename a planet file and all of its moon files
The idea is you use mm sort of like you’d use git — you initialize it at the project level, and then add moons to planets as needed within the context of a project.
By default, moons open in your EDITOR of choice, but I’m thinking of adding support for editor overrides so you can easily open planets in one tool, and moons in another.
I don’t honestly expect many or any folks to use this thing, but I’m excited too. It matches my mental model, and, my process: usually, when I’m working on a project, I end up creating a bunch of temporary or scratch files to document little corners of something, and experiment. This enables that in a consistent way across my projects while maintaining compatibility with all of my existing tools. If this works out, and doesn’t have any toothy gotchyas I’d like to support adding moons, satellites maybe, to specific lines, or regions of a planet file, too. My first attempt at this thing was more elaborate — rather than bash and saving to the file system, I tried to do something with sqlite, and having a database backing each file of a project.
The idea was to support using any convergence of row and column number of a text file as an id, and then generate a connected moon from that. This was a cool idea, but so fragile as to be untenable. Plaintext doesn’t offer a great way to reference specific points in a file if that file is changing.
This post is a slightly modified version of a talk I presented to the product practice at my work. It presents a few ways that product designers and managers can help to move accessibility forward. It is a little bit different than what I normally share, here, but, I thought it may be interesting to some folks.
I’m not gonna make a case for why accessibility is important; my hope is that we’re pretty well aligned around why.
Today I’m going to focus on what product folks can do to push accessibility forward.
The tl;dr of it is that we need to make accessibility a core part of our processes:
- We need to add it to our acceptance criteria and definitions of done if it isn’t there already.
- We need to have a plan for how to improve our products’ accessibility and know that compliance isn’t the goal, but the minimum. It is the floor. There is always room for growth.
- And, as we achieve accessibility, we can celebrate those successes. Sharing how we’ve done it, and why.
Many product folks have shared this meme. It is beloved in the community because it offers a concise vision of product, and tugs at some nostalgic heartstrings while doing so.
I also think that this meme offers a vainglorious view of product.
How annoying would an awesome burial form be? Or a tax form? These shouldn’t be noticed. No one should remember these forms for good or ill because these services are doing their jobs if they work and are totally frictionless.
Most of the products we work on are infrastructure that folks are obligated to interact with.
A real life example of a frustrated experience that we can see today is Namely’s PTO request form. That form takes a sighted person who can use a mouse a few seconds to complete. I urge you to try and complete that form using either a screen reader or only a keyboard. No mouse.
It is a gnarly-cumbersome experience because one of the form fields isn’t directly reachable from the keyboard.
When products aren’t accessible folks don’t have a clear way forward. So, how can we avoid confused, and frustrated Mario here?
The PTO request form on Namely isn’t empowering rad shit, as the meme says, it is frustrating and makes what ought to be a simple task a difficult one.
It makes what should be an unmemorable obligation an annoying experience.
But how do we avoid this? How can product folks help to prevent this situation?
Accessibility is often seen as a concern for UX and engineering — today I’d like to say that product folks are also key to creating accessible stuff.
My suggestion is to stop thinking about inclusion and start thinking in terms of exclusion.
By identifying points of exclusion, those moments where folks are either wholly forced out of your product, or, more likely, have to come up with homegrown workarounds to complete some task, we can start to take actionable steps towards more inclusive products!
Sometimes you may have to make the hard choice of who’s in and who’s out; I think this is the type of choice that product should make, not growth, not sales, not engineering or design. Product should make this call because product often has the longest memory — product folks can back the choice up with data and continually work towards products with fewer points of exclusion.
If someone has to be excluded at least have data about who, and immediately work on a plan for how to bring them in.
Thinking in terms of inclusion tends to lean aspirational, while by framing things in terms of those points of exclusion we can more easily come up with actionable steps to help create more inclusive products.
Again, how though? How can we identify points of exclusion…especially when we’re talking about something that hasn’t been built yet?
We start by examining the assumptions we’ve made and making sure that they are informed by research, and also informing new research.
- Are our assumptions excluding anyone?
- Are there folks who are having to work around any assumptions we’ve made?
The popularization of hashtags on twitter is an example of this, or a child climbing a counter to reach a cabinet in a kitchen.
- Twitter’s initial assumptions didn’t include groups wanting to use it as a tool for organizing, but folks worked around this hole by developing the hashtag. Twitter reacted to this, and baked support for hashtags into the platform.
- If a kid has to climb a counter to reach a cabinet, they’ve been excluded from that space, perhaps for a reason though?
What assumptions informed these choices?
Of course, the best way to interrogate your assumptions is to include disabled folks in the discussion. Folks excluded from your product and the system that produces it — that isn’t always in our power and is a bit out of bounds for this presentation, but, include and prioritize these voices whenever possible.
Next we make sure we have metrics about accessibility.
This, in my experience is the trickiest of my suggestions. A lot of things look and smell like metrics about accessibility, but end up being metrics about delivery.
To help ensure that our metrics are actually about accessibility, which is less an end-state and more a practice, or way of working, I’d suggest that we start by having metrics that focus on our teams’ processes and tracking how we approach accessibility in our day-to-day work.
Rather than track that we delivered some number of accessible components, I suggest that we track that our team has a plan for improving accessibility — like a tiny maturity model — so we can track this improvement in our processes.
For example, a metric tracking the number of components you shipped to production that include accessibility guidance.
Last but not least, don’t hold a meeting where you don’t mention accessibility, and, maybe most importantly, celebrate as you continually achieve accessibility beyond compliance.
We hear a lot about gaps in accessibility, and rarely about victories.
Because of this I think there’s an idea that accessibility is all about compliance and gloom; whereas we have an opportunity to make it about playgrounds and connection and innovation. It can be the next chapter in how we do this thing we do.
That is probably my most important point:
- Celebrate as you achieve accessibility to help show that it is doable.
Just like when “mobile-first” was the catchy rallying cry, we can celebrate and spread “accessible-first” methodologies and help to popularize it as a core principle for any new projects.
Accessibility isn’t the sole responsibility of specialists, it is a facet of the work everyone does.
Achieving accessibility beyond compliance isn’t possible through technical means alone; it also involves a certain amount of cultural change. I think cultural change is a responsibility that a product practice carries.
When folks started to embrace mobile, some businesses did quick fixes to update existing solutions so that they’d work on smaller devices. This is akin to accessibility remediation work.
Other businesses adopted mobile-first design methodologies, making mobile a key principle from which they worked. This is like doing accessibility beyond compliance.
An accessible-first approach, an approach that goes beyond compliance, invites the creation of more adaptable systems that are ready for situations we haven’t imagined yet.
With mobile, folks who had an adaptive, mobile-first methodology were able to take the introduction of tablets in stride, while those folks who’d been focused on only supporting the known form-factors had to do more work to keep up.
Product folks have an opportunity to bring “accessible-first” thinking to their work, and help cultivate a culture that strives for accessibility beyond compliance, and in so doing, ensure that we are all better prepared for anything that might come along.
A huge thanks to Josh and DK for sharing feedback with me while I came up with this presentation.
Some questions to consider:
- What are ways to interrogate your and your team’s assumptions?
- Are there tools that can help with this?
- What are some possible metrics that can be used to gauge the health of your team’s accessibility practice?
- How can you make those metrics meaningful for stakeholders?
- What are ways you and your team can celebrate your successes that can help set you up for more success?
- A higher-level kinda question: what is the role of a product person in helping to define a team’s culture?
I’m feeling pretty chuffed! Last week I wrote about my intention to make this website more accessible. My motivations were many-fold, but, primarily, mostly shame. I’ve worked as an accessibility specialist in the past, and now spend a bunch of my days at work looking for ways to make public infrastructure online more accessible. It seemed fitting to at least make sure the little bit I contribute to the web here is also accessible.
I thought it was going to be more of a project than it ended up being. Oatmeal is passing with mostly flying colors according to a couple different browsers’ in-built accessibility auditing tools, VoiceOver, axe, WAVE and IBM’s accessibility scanner.
I focused on improving a few key areas:
- color contrast
- markup structure
- navigation
To achieve better color contrast ratios I know I could have employed math, but, instead, I didn’t do anything scientific — I used trial and error to land at a slightly updated color scheme. Along the same lines I also increased the default text-size and made sure that link text was visually unique along an axis other than only color. Underlines, baby!
The markup was the issue that had me thinking I was gonna have to do a soup to nuts rewrite. I ended up finding a handful of big wins, though, so was able to make a lot of progress pretty quickly. The biggest win was tearing out a lot of indieweb-specific markup. I think it isn’t that hCard’s and what not aren’t accessible, they just lead to a really “chatty” page if poorly structured, and mine were poorly structured.
The markup updates flowed into improving the navigation. I’ve always leaned heavily on this being a blog, with everything structured around a gigantic chronological list of posts. That’s boring, though, and not all that conducive to actually finding stuff that isn’t chronologically recent.
The site’s navigation still lives mostly in the footer. Now there’s a skip link to get there more easily (try it! Use the tab key to trigger the skip link). I’ve also added a handful of new pages that invite folks in through some different entries — doors and windows and whatnot.
With these changes made, I’m feeling better about the state of this thing. There is 100% certainly more that can be improved, though, so, I’m gonna consider this the start of an ongoing project.
The worst kind of blogging is blogging about blogging, so, I’ll keep this blogging about blogging short!
I’ve made some minor updates to the design of the website that have improved it’s usability a wee bit, and are a step in the right direction toward upping my accessibility game. The major remaining accessibility issues are around color contrast and some structural stuff.
I’ve started to introduce an updated color pallet to resolve the contrast issues. The structural stuff is going to be a wee bit harder to address, but I’ve started to make inroads there, too, mostly by removing a lot of indieweb specific microformat markup. The entire site should be more or less totally navigable by keyboard now.
I’ve also added a page to help situate folks and invite ya in to different ways of finding stuff here.
“I am Batman.”
It got a wee bit cold here in Maine this weekend. It was thankfully uneventful for us. We hung around inside and watched it get real cold outside. Our home faired pretty well, too. Honestly pleasantly surprised about that!
We picked this weekend to go all in on potty training — pantsless days, treats, rousing bouts of encouragement sung, and a lot of spot cleaning. Fueled by hubris, I thought we had this potty training thing down pat. In reality, it was that our first go round with it was supremely uneventful. We will perceiver.
I’ve been thinking many thoughts about how to fix this website. While I love its design and general vibe, I know it’s not all that accessible, and has some usability issues (so many tags!?). I don’t have a real idea what to do, yet, but maybe take this as warning? Changes are afoot…albeit a pair of slow, uncertain feet. Things I hope to figure out include
- an equally quirky, but significantly more accessible design
- a better way of revisiting past posts
- and if I even wanna stick with this blog-ish format, or if I wanna move to something more like a wiki, or something altogether weirder!?
I recently asked a question on fedi:
Once upon a time I was an art history person. I thought for a long while I was gonna be a professor of it or something adjacent to it.
There’s a certain sort of art history writing that spends a lot of time establishing an ontology around what’s beautiful, and what moves make something beautiful.
These days, a lot of the nonfiction I read is about programming or computer science. It’s not unusual for a programming book to talk about beauty in code, or data, but the “rules” for what makes something beautiful seem a lot more ephemeral, but usually related to “elegance.”
For the code inclined among ye, when do you see code as beautiful? Do you?
This had a number of really interesting responses that I’ve been noodling on. If I was so bold as to condense them down, I’d say a connecting line between all the responses is “utility.” In hindsight this makes total and complete sense — code ought to work. When I asked the question, though, I was in a really aesthetic frame of mind, so, was sorta surprised with how focused folks were on the code actually functioning over some aesthetic quality of the rendering of the code itself.
…but this may also be sign that my code is mostly garbage?
In my mind, regardless of what or how it works, C is less “beautiful” than a lisp. There is an aesthetic to lisps that I find beautiful.
One respondent said,
I find code beautiful when it has an internal grain, a style of its own, whatever that style may be.
That struck me. I’ve read about the idea of code having “grain” before, and find that an interesting way to describe the tactile nature of programming systems when compared to one another…C to lisp, forth to pascal.
Since the new year I’ve finished a few books. I’m trying to read more fiction than nonfiction this year. I re-read The Hobbit with the family, and an unremarkable, but enjoyable book, the second in a series, Eyes of the Void, by Adrian Tchaikovsky. I liked the first in the series better than this second one, but it was fun, and I’ll most likely end up reading the third installment soon enough.
715 Creeks by Cristin Milioti is a song that has been in heavy rotation while I work lately. It is a cover from Bon Iver’s 22, A Million.
“I’m on a boat.”
Snorlax leaning into the whole vibe of her namesake.
At the start of this year I set out to revive my long dead reading habit. After having kids it fell by the wayside. I’ve read 41 books so far this year. Mostly a mix of science fiction and nonfiction computer science books. Here’s the complete list of everything I’ve read. I’ve got mixed feelings about keeping track and sharing counts of whats been read in a year — it isn’t about quantity, but I do enjoy being able to look back at a log of what I’ve read.
Some notable works:
Record of a Spaceborn Few, by Becky Chambers took my breath away again and again, a book that hooked me right from the start.
I loathed nearly every moment of The Ministry for the Future, by Kim Stanley Robinson.
Madeline Miller’s Circe was one of the most beautiful things I’ve read in a long while.
This is How You Lose the Time War, by Amal El-Mohtar and Max Gladstone was probs my favorite read of the year.
Programming from the Ground Up, by Johnathan Bartlett is one of ’em that I want to revisit because I know I need to pay better attention to it than I did the first time round.
I didn’t set out to read mostly science fiction and computer science books, I sort of fell into them. I’m thinking next year I’ll follow some whims and build some themes to read around; mystery is top of the list.
After engaging in my little tour of computer science flavored books I think most programming books do too much of the wrong thing. Rather than pick a lane and run, they float between a few spaces:
- Tutorials, learning-oriented (teaching someone to cook)
- How-to guides, problem-oriented (a recipe for cooking a specific thing)
- Explanation, understanding-oriented (historical overview of an ingredient’s cultural importance)
- Reference, information-oriented (an encyclopedia article about an ingredient)
I think there is a lot of space for programming books that don’t try to be everything, but pick one of the above and go all in.
I think each of these types maps fairly well to an audience:
- Tutorials are for folks who are totally new to a thing
- How-to guides are a step up from tutorials and help you learn idioms and best practices of a space
- Explanation is useful when needing to convey the value of a thing
- Reference is generally for experts who are cozy doing the thing
Instead, most programming books try to be everything to everyone for every occasion. I think just about all the books I read had a preamble about “who’s this book for” and they’re all basically for the same kind of person according to all those preambles…someone who isn’t necessarily an expert, but familiar with the basic concepts of programming.
…but maybe this is also biased by the sorta books I was picking up?
What follows is my attempt to spark a conversation in a few converging, but separate communities I lurk in.
I’ve already had a bunch of amazing conversations around this topic with a lot of people. Those conversations helped to shape what follows. Thanks to everyone who was willing to think this stuff through with me.
Before I get into it I want to say at the top this isn’t meant as an accusation against anyone in these communities, nor the goals of the various projects. This is intended to add a new layer to the existing considerations and to see if the goals of these projects can be expanded to include, or consider, accessibility.
I want to open a conversation about accessibility in this space.
I think it is an important consideration mostly left out of our community’s conversations.
I think it’s an important conversation for a variety of reasons —
Facet, ignoring it tacitly implies there isn’t space for folks who rely on assistive tech in our community, that they can’t contribute and aren’t imagined to matter in the future.
Facet, we often look back in time to older devices, implementations and implementers. For many of them the concerns of capitalism placed constraints on what they could achieve. We’re speculating about a post-capitalist ecosystem…as such, we have an opportunity to think outside of those confines. Thinking about accessibility invites us to look forward while also pulling inspiration from the past. We have constraints, they’re a different looking set than the ones on things like the apple 2, we needn’t let those constraints define our future.
Before I turn the conversation over I want to set a few core assumptions:
- accessibility is more than screen readers
- disability is something that takes a variety of forms, it is something some folks live with forever, it is something that visits some other folks briefly
- disability can compound; sometimes we need to consider more than 1 disability at a time
- disability can be visible, disability can be invisible
A first instinct may be to think of accessibility as a technical problem that needs a solution. I’d suggest that it might be an opportunity to reframe how we approach the idea itself; from accessibility to adaptability. Adaptability of methodology, problem solving, software, and devices.
Break thrones. Build tables.
Over the past couple years I’ve done the advent of code to varying degrees. I thought I was going to do it again this year but decided to try something different. I’ve been calling what came together a “December Adventure.”
It isn’t anything fancy; throughout December I aim to write a little bit of code everyday. So far I’ve written a bit of apl, bash, elisp, explored a bunch of flavors of scheme, and started to (but not yet finished) write applications in racket and lil.
A few other folks have joined in — to make it a bit of a community event some of us started to log our adventures and post about them…but there aren’t really any rules. One of the reasons I didn’t want to do the advent of code again was that it was feeling really competitive. A couple years ago it felt fun, playful, but these days it seems pretty corporate and less about exploring or learning anything new and more about being the quickest, something that I think is sort of endemic across the industry: quick is more important than curiosity.
I’ve been enjoying it, and it has been fun to keep up with everyone else’s December adventures.