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!

I think about evolved antennas a lot. If you’re not familiar, an evolved antenna is created when you set an evolutionary algorithm on the task of producing a structure that is as efficient at its intended function as possible. Past that there’s no human input, the algorithm just does its thing. It: Modifies elements of the initial design, Evaluates how well the design would perform according to a set of requirements, Adds or discards the changes accordingly, then Repeats until a success threshold has been achieved via iteration. Some evolved antenna practices also create a series of designs in parallel. They then pit the outputs against each other as a final layer of proving out efficacy. This process mimics natural selection. Here, mutations that are beneficial to surviving in an environment are passed through generations. It also creates absolutely wild, alien outputs: Source: Human-Competitive Results: Evolved Antennas for Deployment on NASA’s Space Technology 5 Misson - SlideServe. An evolved antenna looks the way it does because the algorithm that creates it is focused on the efficiency of the artifact it produces. It has no concept of what antennas are “supposed to look like”. That’s a bias that is inherent to us humans. Structural limitations I also have a light fascination with early programming. Specifically, the creativity involved with how programmers accommodated limitations inherent with the medium. Early mainframe programmers were constrained to the point where there would be a limit on the number of characters you could use, which led to cryptic names that oftentimes required a physical dictionary to look up the human-friendly meaning of something. There was also a long tail of this practice even after the hardware-imposed restrictions of the mainframe era. This was likely built on muscle memory, “best practice”, and a DRY mindset taken too far. Fortunately, contemporary practice—where computational power is far more luxurious—favors clarity over brevity. Profusion and proliferation Nowadays function and variable names are long and luxurious. We’re inundated with text. Flooded by it, even. In fact, we’ve gotten so good at using text that we built software to produce it for us, on demand and at volume. There have been some good things to come out of this development if you make digital experiences for a living. Concerns such as documentation, design systems, styleguides, and other vital-yet-neglected areas of the practice are suddenly critical for operations. It turns out that written words that help to explain things and create consistency are extremely important. Who knew! Here, I must confess: As someone who has long-favored these downplayed and underfunded areas of the trade, I have found myself ugly laughing at this tragicomic phenomenon. I also know that being able to feel this smug ruefulness is on borrowed time. Returning to this sudden explosion of text content—as well as other factors—we now have words for everyone who wants, or may eventually need them. Well, anyone who can pay. Decoupling and system gaming Many contemporary LLM-providing companies operate under a model where you pay them proportionate to how much computational power you utilize. This is sold via tokens, which is an abstract representation of a segment of content to be processed. Money is something people are reluctant to part ways with. This creates incentives to get creative. I’ve read all sorts of clever techniques, tricks, optimizations, and hacks people have created to lower token expenditure. The one that stands out to me most is the caveman prompt. It promises to “[cut] 65% of tokens by talking like caveman”. Of note is its ability to specify the level of “grunt”: Futurecasting The caveman prompt is a signal. Right now we live in a space where full, complete words and sentences are still desirable for us humans, and LLMs work with it. This space is in competition with a few intractable realities: LLM companies are continuing to operate at a loss. The real cost of using their services may manifest sooner than later, as promises of profitability need to be kept. Human language is an inefficient medium for transmitting data, and largely lacks the precision needed to describe the logic that powers contemporary software. Consider concepts like Robot Interaction Language and ggwave as ways we’ve attempted to address this fact. LLM-based product development is focused more on what is produced compared to how it is made. Given these considerations, one can imagine a future where human-friendly language is a liability. The forces of cost and efficiency are difficult to overcome, especially if results can be generated with minimal effort. One can also imagine that code returns to its infant state of being terse, cryptic, and near-impenetrable due to efforts to optimize how LLMs operate. Here, human language sets the parameters and LLMs act as the dictionary. This LLM optimization might even go a step further. In the pursuit of efficiency its code output becomes a language completely decoupled from a human’s ability to follow. In the torrential downpour that is everyone saying the quiet part out loud, the CEO of OpenAI’s horrifying comment about selling our intelligence back to us is a raindrop worth paying attention to. This possible outcome may mean that this time around there is no dictionary to reference. Or there is a dictionary, but it is sold back to you at a premium. It’s easy to foresee a proprietary language that only a LLM vendor can compile, decode, and otherwise change—it’s not like there’s a lack of prior art. Preventative measures Science fiction author Vernor Vinge wrote a brilliant book titled Rainbow’s End. In it, a character named Robert Gu is cured of his Alzheimer’s and brought into a post-singularity world. Gu—a former English professor and avowed technophile—struggles to adapt to a radically changed world. In one notable scene from the book, Gu rages when dismantling a device. He finds all its internal components are sealed and labeled, informing him that there are “no user-serviceable parts within”. Code may be poised to follow this direction. Imagine a world where attempting to open up any piece of software reveals a dense forest of evolved antennas, each constructed using inscrutable, black box language. Gu's outburst of anger is valid. It stems from understanding that intentionally preventing someone from making modifications is a method of enacting control. Another notable part of the future Rainbow’s End posits is the mass-proliferation of augmented reality. Here, people can access different “layers” of perception, with paid tiers of information. Looking with your naked eyes is free, but the more information you want about something the more you need to spend. Craft and cost As someone who cares about craft, I am deeply worried about this potential future. How something is built is just as important as the results it produces—reference LLMs' bias towards producing inaccessible code as an immediate concern. Inaccessible output by default is a case of implicit and unwitting control, in that it shapes who can—and cannot—use the web. The companies that provide these models could hypothetically be compelled to address that. However, the much-needed regulation needed to prevent this systemic digital exclusion is unlikely to happen with the current status quo. Or more realistically, will happen in a way that is more in-line with the regressive path the United States is currently traveling down. Some here may argue that these systems are performing better than how human developers have, and that will increase as LLM-generated code becomes more prevalent. Here, know that: As of now, homepage accessibility errors and complexity are both on the rise, and This increase in inaccessible code will continue to be enshrined, codified, and amplified as the source code is re-scraped and fed back into model data training efforts. Websites are being built via LLM-generated code and populated LLM-generated content at an exponential pace. This, in turn, raises more concerns: Overcoming this ever-increasing inaccessible default becomes progressively more resource-intensive. This makes it something only larger organizations can afford to take on, yet will be unwilling to due to a proportionately scaling cost. Inaccessible outputs become increasingly more normalized. This makes it ever more unlikely to be questioned as something that needs intervention. Command and control More distant—yet more relevant—fears center around explicit control. We're already seeing this manifest with refusals to communicate facts that may be inconvenient for LLM providers’ success. More abstractly, this entire model of operation is antithetical to one of the most radical and equalizing forces humans have ever invented. And subversion of this model is deliberate. You must imagine Sam Altman holding a knife to Tim Berners-Lee's throat. Anil Dash The public internet has been available for 35 years, and open source for 28. Both are revolutionary ideas that upended traditional ways of how knowledge is distributed. The lifespan of these ideas are also tiny blips compared to the centuries of traditional power structures and systems that came before them. It’s also enough time for said structures and systems to figure out how to address these existential threats and return things to how they prefer to operate. Being robbed of the profound openess and transparency we have become accustomed to means that we place control of reality in the hands of closed, unaccountable organizations. Here, we need to think deeper than code. Antifuture There is a potential future where we are lead down a path that works against our own self-interests, amnesic to how we wound up where we are and without the language to communicate it. Dominant players are contemptuously bypassing the standards process. We are already seeing attempts to manipulate LLM output to serve political agendas. Even further, this manipulation can occur with the providers themselves. Also recall that the more unaccountable LLM output is normalized the less we will question its outputs. Now be the villain and imagine what is possible if these agendas feel threatened. Before the internet there was Usenet. Before Usenet there was ARPANET. Through this lens, the browser is just another place information is stored. Here, we should be worried about the wolf-in-sheep’s-clothing threat of monopolistic vertical interoperability—interfacing what came before as a method to subsume it. You may be reading this post as a paranoid fear response. I should point out that these fears are cultivated. Here, know that I am not feeling fear as much as anger and a desire to preserve what is boring and works. You can open Notepad and type whatever you want into it. You can open Paint and draw whatever you can imagine. You can publish whatever you want online with a small degree of technical know-how. This all costs nothing past the hardware, software, and connection fee. We take this for granted, to our own detriment. Being open and transparent is a radical strength, not a weakness. We should not throw this away in the pursuit of a convenient perceived inevitability.

A bold first sentence that draws you in. A steering second sentence to set you further down the path. A third sentence that tantalizes and alludes to content to follow. Following is an initial explanatory paragraph. It serves to help back up the previous paragraphs, and start to ground it in more applicable information. Expectations are set, and potential skepticism is addressed. A link to prior art is supplied, to provide additional context. There is then a paragraph that serves as a segue. It connects the high-level concepts and begins to draw them down the realm of the practical. A subheading to help segment the content This paragraph begins to answer the questions in the reader’s mind that the segue paragraph introduced. It begins with level-setting. Certain key concepts are bolded to accommodate people who skim. Following that is supplying more context, albeit still at a relatively high level. A short sentence isolated as its own paragraph to drive attention and impact. The following paragraph begins to dive into particulars. It introduces a new concept related to the subsection’s topic at-hand, careful to stay focused to help the reader understand the larger goal you’re driving towards. Bulleted lists help the reader digest these particulars, Break up the flow of content, and Step through a process. A follow-up paragraph at the end of a subsection may allude to the author‘s opinions or larger thoughts about the topic. It also sets up the next subsection. Another subheading The next concept is addressed, getting more technical as the reader becomes more acclimated. A link to a peer resource is threaded in as an appeal to authority, to help reinforce confidence in the author. An ordered list is used to: Communicate a series of instructions the reader should take, In which order they should be followed, and Do so in a way that both makes it easy to follow and also breaks up reading flow to be more noticeable. There might then be another follow-up paragraph. This one might contain a sentence with an em dash—indicative of a trailing thought that is still topically related. A deeper subheading This section works deeper into the technical topic. It dispenses with reasoning and analogies and discusses practical specifics. A piece of code that translates the practical specifics into language a computer can be instructed with. Comments are supplied to help facilitate understanding. A bulleted list is used, It breaks down and explains code concepts that may not be self-evident, and These points may be more holistic, meaning they aren’t a good fit for inline code comments. A new concept is introduced We break out of the depth of the deeper subheading’s content and return to a level higher. This is a new concept, yet still living under the umbrella of the overall topic at-hand. The format of this new concept mirrors the structure of the previous section. This predictability helps with reading flow and answering the reader’s unspoken expectations. A subheading that begins to tie all the previous sections’ content together This subsection takes each of the previous points raised and reinforces their need to be sequentially discussed. It then explicitly confirms the case the rest of the content has been implicitly building, that this topic was worth breaking down to better appreciate as a holistic whole. Some established trust is cashed in. The author is allowed some space to wax philosophical about larger implications, or discuss their feelings on the matter. A conclusion The bold first sentence is revisited now that the reader has completed learning about the concept being discussed. A subsequent sentence explicitly ties the nuance the rest of the content discusses to the overall point. The reader is thanked, and the content ends.

Hey there, fellow designer! Chances are good you’ve been linked to this after doing some annotation work on a design you've been creating. First off, I want to thank you for taking the time to address accessibility considerations in your work. No, seriously. I mean it. Accessibility-oriented annotations are still a relatively rare thing in our industry. I applaud your efforts to buck that trend, and hope that this post does not dissuade you from future attempts. On focus order There’s a subtle thing at play here, and it mostly revolves around the notion that adding something demonstrates effort and value. For focus order, you’ll actually want to suppress that urge and just let things be. Yes, many accessibility annotation kits do come with the ability to specify focus order. And yes, being able to place focus on the interactive parts of your website or web app is an important thing. However, interactive elements allow you to place focus on them without needing to do anything else. This includes buttons, links, form fields, checkboxes and radio buttons, expand/collapse toggles, tab panels, etc. This is possible if the engineer—or LLM—who builds the user interface (UI) uses semantic elements. This means things like the button element for buttons, the anchor element for links, etc. Also know that it is a whole other set of problems if semantic elements aren’t used. The order itself When it comes to web accessibility, the order interactive elements receive should be a logical order. For the vast majority of situations, this means matching reading order. For example, English means focus order is left-to-right, top-to-bottom. Arabic means right-to-left, top-to-bottom, etc. The easiest way to guarantee focus order matches reading order is to ensure the underlying HTML that powers your web experience is written in top-to-bottom order, where the width of the viewport controls where content flows to the next line. Fortunately, top-to-bottom HTML order is how the majority of the web is still built. If you don’t believe me you can spend a little time poking around with browser developer tooling. I like using the inspect element feature for this because you can highlight UI in the browser tab and see its corresponding code in context of the rest of the page or view. Why is focus important? A consistent, predictable, and logical focus order helps a large number of people use your website or web app. This includes working with assistive technologies such as: Screen readers, Magnification, Voice control, Switches, Etc. It’s also something I’m willing to bet you’ve benefitted from when filling out forms, using Tab to quickly jump from input to input. So, why do annotation kits include focus order options? Honestly, good question. Focus order annotations serve two general use cases: When the HTML order does not match reading order. This sometimes happens as a result of third party code, some relatively obscure CSS layout techniques, or other corner-case scenarios. When you need to do deep custom UI work. There are certain kinds of complicated components and flows that benefit from having the order of focus explicitly illustrated for development handoff. For example, I used them when helping to make GitHub’s interactive list component. What should I do instead? If you want to use your time efficiently: There is a tremendous amount of value in manually evaluating focus order on the developed UI. And it’s easy to perform manual evaluation! All you have to do is press the Tab key and ensure each time you do that: There is a visible focus treatment applied to each interactive piece of UI, and Focus moves in the reading order of the language used for the design, and does not skip anything over. You’ll want to do this on the live, public version of the website or webapp, since that is what the people who use your service will be using. Then file bug reports in the appropriate places if you run into things not working as expected. As a pro-tip, you can also prime your focus so you don’t have to Tab over primary navigation and other templated interactive elements repeated across different pages or views. Given that assumptions are just that, you could also look into explicitly documenting: HTML order should follow reading order, and also Semantic HTML should be used for interactive elements. Be strategic in how you go about this. It might ruffle some feathers, especially in larger and more siloed organizations. Other misconceptions While I have you, here are a few other missteps related to focus order that I’ve encountered. These all break expectations and may confuse and disorient the people who use your service: Manually orchestrating a designed experience for where focus should go via use of tabindex. Making inert, static text focusable to make it more “important”. People already have ways to work with this kind of content. Removing the ability for interactive elements to receive focus in an attempt to direct someone to features the organization prioritizes. Assuming engineers know what component you’re using in your design, and where its documentation lives. Annotating the repeated, templated parts of a page or flow that have already been developed. Again, thank you Meryl K. Evans has a quote about accessibility that I try to live by, and that is “Progress over perfection.” To that point, thank you for being open to reading this post—I hope you don’t feel anger, shame, frustration, or other negative emotions in response to trying to do the right thing. I also hope that you don’t drop your accessibility efforts all together. Instead, know that making the web a little bit more accessible—and therefore a little bit better—adds up over time. This also includes how you learn about the details and nuance of designing for disability. One of the web’s better capabilities is its ability to be revisited and updated. It means that past efforts can be improved on as easily as making something new. In a way, it can also be a form of kindness you can extend to your past self—it’s something I’m trying to do. In closing, I’ve included a list of more resources at the end of this post. I hope it can serve as a springboard to learn more about focus.