More from Eric Bailey
My last official contribution to GitHub was something I’ve wanted for a long time: Writing the code to display an ACCESSIBILITY.md file’s contents on the repository landing page. This content lives in the same tab component that the README, License, Code of Conduct, Security, and important information is surfaced. For example, I’m using an ACESSIBILITY.md file located in ./github to communicate my accessibility statement on my a11y-webring.club repository. Here’s an image of it in action: The file only appears if it is supplied, so it is not a required part of creating or maintaining a repository. However, it is my hope that the act of providing one becomes more commonplace the same way providing those other special kinds of files are. Another broader hope I have is that this promotion of content helps to normalize accessibility as a consideration and practice in some small way—something that helps to send a signal of a mature software project. I’m excited to see how people use this new addition to the platform. I would also like to extend a huge thank you to Jan Maarten and Maria Lamardo for their help getting this effort across the finish line.
I owe a lot of my professional identity and success to CSS-Tricks. CSS-Tricks repeatedly gave me the opportunity to write for them. In doing so, they helped to both socialize and normalize accessibility as a mainstream frontend concern. I’m deeply thankful to them for this. The team was also a joy to work with, notably Geoff Graham. He’s a mensch, and one of the nicest people you can interact with in the frontend web space. If you have not been following the news about the site, Kevin Powell has a good video about the whole situation: Content skipped. I’m not speaking on behalf of Geoff, Chris, or others involved with running the current version of CSS-Tricks. I’ve got skin in the game as an author. This is my personal opinion, born of my feelings and beliefs. I think a lot of the web’s infrastructure should be co-ops, and CSS-Tricks is knowledge infrastructure. To that point, I should also point out that the website covers far more than just CSS. The corporate model of ownership can be a risk. If infrastructure is not part of a corporation’s core strategy, it is not a priority. As Kevin’s video touched on, it seems like promotion via owning the frontend content space isn’t part of Digital Ocean’s strategy anymore. It is not that CSS-Tricks does not have value. It is that Digital Ocean cannot see it. It is deeply, tragically ironic to me that Digital Ocean allowed this to transpire. This is because I know for a fact that the techniques and philosophies shared by CSS-Trick authors helped to shape iterations of their product’s UI. Some may be quick to point out that this knowledge now—illegally—exists inside of LLM training data, so the risk of the website going away is mitigated. To this, know that we should be striving to keep resources like CSS-Tricks going. Human creativity is the force that creates new techniques, strategies, and technologies. The web will calcify without voices sharing what they know, forever locking us into endless permutations of a fixed point in time. Unlike corporations, co-ops don’t have to be motivated by profit. By not needing to prioritize growth at all costs it means co-ops can instead prioritize and incentivise things like preservation and cultivation. It is also a successful model of operation, one that even already exists, and flourishes in the tech space. Collective ownership can also serve as checks and balances for, and protection against hierarchical decision-making. I only need to point to the chaotic and aberrant decisions many CEOs in the technology space have been making as of late to demonstrate the value of this approach. Paddy Srinivasan, if you somehow wind up reading this: Save some face and take a big swing. Give CSS-Tricks back to the people who love it.
The city next to the town I grew up in had a shopping center that was built atop a sanitary landfill. For those unfamiliar, creating a sanitary landfill involves taking landfill waste, spreading it into thin layers, compacting it, then paving over it. It enjoyed popularity as a practice in the 60s and 70s. I’m all but sure this shopping center was built in the mid-to-late 70s. It was the 90s when I was a kid and started going to it. Of note was a Kmart that I’d frequent with my parents when running errands. At some point, the certain parts of the tile floor of the Kmart started to buckle and bubble—their edges tinged with an ominous yellowish brown color. The reason for this is that is that the landfill was sealed improperly—accumulating methane and carbon dioxide gasses was pushing decomposing waste upwards and outwards. The employees put up some warning signage around the worst of it, but that was pretty much it. They did not have the expertise, nor the incentives to do anything past indicating the problem. One day we tried to go to the Kmart, and it was closed for good. A few years later the entire shopping center had to be demolished and the landfill had to be dug up and disposed of.
I made an app! What Can’t I Press? is an app that allows you to: Read, search, and filter through screen reader keyboard shortcuts. Scan open apps and add their keyboard shortcuts to the collection. Copy a keyboard shortcut to your clipboard, with modifier keys to format the keyboard shortcut in different ways. Export the list of keyboard shortcuts in its current state as JSON. It is intended to be both a reference and a discovery tool. Here’s a quick demo of it in action: Two open apps placed side-by-side on macOS: TextEdit and What Can't I Press? TextEdit is open to a blank document. What Can't I Press? shows a search input, an expand/collapse all toggle button, a list of 4 disclosures in a collapsed state, a notification message, a shortcut filter input, a download icon, and two buttons labeled "Scan all open apps" and "Scan last focused app". The disclosures are labeled, "JAWS", "Narrator", "NVDA", and "VoiceOver" and each has a badge tallying how many shortcuts are present. The notification message reads, "What Can't I Press cannot detect all possible keyboard shortcuts. Be sure to also check manually." The mouse cursor clicks the "Scan last focused app" button and a brief scan happens. The list of disclosures updates to show global keyboard shortcuts and shortcuts for TextEdit. All disclosures are set to an expanded state, and links to jump to the next section are also revealed. The mouse cursor then clicks on the search input, where the word "save" is entered. It then briefly scrolls through the list to show what apps have functionality related to saving. The search input is cleared by clicking a clear button, then focus is placed on the filter input, where Commandkbd> + s is entered. The list of keyboard shortcuts filters to show all shortcuts that incorporate these keystrokes. The cursor then clicks on the Commandkbd> + S save row button, and places focus on the TextEdit document. The content "⌘S" is inserted into the document via pasting. The app is also available as a web experience, and can be installed as a Progressive Web App. This form of the experience only allows viewing and filtering screen reader keyboard shortcuts, as scanning open apps is not possible using current web technologies. Why did I make it? App and webapp keyboard shortcuts are an often overlooked area of user experience, especially when it comes to working nicely with assistive technology. As much as possible we should not put the burden on the person using assistive technology to use workarounds. In other words: what is added as a convenience for someone who doesn’t require assistive technology should not impair someone who does require assistive technology functionality to get what they want or need. I made this app to help speed up and streamline the process of adding keyboard shortcuts in a safe and responsible way. For more background on this act, reference my post, How an accessibility designer adds keyboard shortcuts to a web app. Limitations What Can’t I Press? cannot detect all keyboard shortcuts used by an app. Consider this as a tool that helps as a first pass, but always be sure to also manually check. There are specific ways of declaring keyboard shortcuts in code that can be picked up by a scan, but not everyone uses those methods. Microsoft is an especially poor actor in this regard. The app is also currently unsigned. This means you’ll have to bypass operating system warnings about installing unsigned apps. All app source code is on GitHub and set to public, so you can review exactly what you’re signing up for. Getting the app signed is on the roadmap, so consider this more of a soft-launch announcement. Is it free? Yes. This kinda reads like you think all keyboard shortcuts should be rebindable Also yes. Looks like you used a LLM to make this A third yes. I honestly couldn’t have made this without it, and I have complicated feelings about that. Believe me, there was a ton of human intervention required. What’s with the icon? It’s a stovetop gas burner. You shouldn’t press it with your hand. I’m really funny, I know. And what about this anecdote that I couldn’t resist sharing? A friend mentioned one of their coworkers uses an app whose main mode of operation is text entry. For whatever reason, pressing Command + b toggles open a navigation drawer, and not, you know, apply bold formatting. This isn’t even an accessibility issue, it’s straight-up bad design. Is this app helpful? Let me know!
More in programming
Google told K-12 schools they could turn off AI, but only if they gave up search too. That isn’t integration. It’s holding education for ransom.
Once a year at my church, I usually give one sermon. I was asked to tie the theme to a young adult retreat we had taken to the Sunshine Coast. My first experience giving a sermon was many years ago at my old home church in El Monte, California. It was a Vietnamese-American church, but…
Practical tools for design engineers to explore possible futures through speculative design
As with my last post on AI, let me open with a statement: Just because most people hold AI a certain way, doesn’t mean that we always must, either now or in the future. As I noted in that piece, and my shades of gray post, I am well aware — and agree with — … Continue reading Must we always use LLMs this way? →
The CSS Working Group resolved to use cursor: pointer for buttons and other clickable form controls in the new appearance: base styles. That happened on October 21, but I posted about it yesterday and, uh, people have feelings about cursors. I wrote about buttons and cursors back in 2022, when a post titled "Buttons shouldn't have a hand cursor" was making the rounds. I admitted I didn't have a strong opinion either way, then argued that not using the hand cursor had become the new anti-pattern anyway. The web isn't an operating system, and people expect clickable things to show a hand. The issue is Cursors For Base Appearance in CSS Forms Level 1. The group adopted the rules from this comment, and the part that's triggering half the Web is: select, option, input[type=checkbox], input[type=radio], button, input[type=button], input[type=submit], input[type=reset], input[type=color], input[type=image], ::file-selector-button { cursor: pointer; } It seems like we have a tabs vs. spaces sort of debate. Again. Nicole Sullivan pulled cursor data from a bunch of design systems and, in September, 27 of the 33 systems that set a cursor used pointer. After she added more systems, it was closer to a 50/50 split. Elika Etemad made the usability case in the meeting. Per the minutes, she said the hand "makes it clear, as soon as you're hovering an interactive control, you're supposed to click on it," and called it a "usability benefit even if not historically done on some platforms." "But the hand means it's a link" Haz had an interesting reaction: The debate is over, and evil has won. His point is that he can't tell whether ⌘-clicking something will open it in a new window anymore. He feels more confident clicking a button when he knows it won't change the URL, like when it just opens a popover or a panel. He's not wrong about that.* I replied that I've been on team evil since 2022 (albeit without a strong opinion, just following what users seem to expect). Touch screens don't have a cursor at all, and on desktop, browsers show a link's URL in the corner when you hover it. That's some type of hint, at least. Haz pushed back that he'd have to watch the bottom-left corner with his peripheral vision, which is fair. He also said he never cared which cursor buttons got, he just wanted links to have their own. I can appreciate that. "But desktop apps don't do it!" Jacob Paris liked the standard cursor on buttons because it makes web apps feel more like desktop apps than websites. My opinion hasn't changed, though. People have already learned that a hand cursor means clickable on the Web. It's by no means mandatory, but it's familiar and satisfying, so it stuck. Either way, nothing changes today. The resolution only covers appearance: base, which browsers haven't shipped yet. Buttons and selects still use appearance: auto, and their cursor is still default. If your CSS reset, design system, or web components already set cursor: pointer on buttons, keep it. When appearance: base ships, controls that opt in will get the same cursors by default. But remember, these are only defaults! You can still add whatever cursor you want to whatever element you want. Nobody's gonna stop you. In 2022, I said I'd keep changing the cursor on buttons until there's a good reason to stop. In 2026, I still haven't found one…and neither has the CSS Working Group. *Thinking about this more, if 50% of design systems opted to add cursor: pointer to buttons already, isn't this already a moot argument? **In general, I think the Web should be more personal and expressive so who even cares about a default? This is especially true for personal and fun sites. Just don't go too crazy, especially when it affects accessibility and the overall user experience.