Online Resource

Online Resource

Online Resource

Online Resource

Hayden Library - R690.W67 2019

Online Resource

Online Resource

Online Resource

Online Resource

Hayden Library - R746.A2C5 2018

Online Resource

Online Resource

Online Resource

Online Resource

Take advantage of the new element and new features of in your next responsive website.

Accessibility can be tricky. There are plenty of conditions to take into consideration, and many technical limitations and weird exceptions that make it quite hard to master for most designers and developers.

I never considered myself an accessibility expert, but I took great pride in making my projects Web Content Accessibility Guidelines (WCAG) compliant…ish. They would pass most automated tests, show perfectly in the accessibility tree, and work quite well with keyboard navigation. I would even try (and fail) to use a screen reader every now and then.

But life would give me a lesson I would probably never learn otherwise: last October, my abled life took a drastic change—I started to feel extremely dizzy, with a constant sensation of falling or spinning to the right. I was suffering from a bad case of vertigo caused by labyrinthitis that made it impossible to get anything done.

Vertigo can have a wide range of causes, the most common being a viral infection or tiny calcium crystal free floating in the inner ear, which is pretty much our body’s accelerometer. Any disruption in there sends the brain confusing signals about the body’s position, which causes really heavy nausea, dizziness, and headaches. If you’ve ever felt seasick, it’s quite a similar vibe. If not, think about that feeling when you just get off a rollercoaster…it’s like that, only all day long.

For most people, vertigo is something they’ll suffer just once in a lifetime, and it normally goes away in a week or two. Incidence is really high, with some estimates claiming that up to 40% of the population suffers vertigo at least once in their lifetime. Some people live all their lives with it (or with similar symptoms caused by a range of diseases and syndromes grouped under the umbrella term of vestibular disorders), with 4% of US adults reporting chronic problems with balance, and an additional 1.1% reporting chronic dizziness, according to the American Speech-Language-Hearing Association.

In my case, it was a little over a month. Here’s what I learned while going through it.

Slants can trigger vestibular symptoms

It all started as I was out for my daily jog. I felt slightly dizzy, then suddenly my vision got totally distorted. Everything appeared further away, like looking at a fun house’s distortion mirror. I stumbled back home and rested; at that moment I believed I might have over-exercised, and that hydration, food, and rest were all I needed. Time would prove me wrong.

What I later learned was that experiencing vertigo is a constant war between one of your inner ears telling the brain “everything is fine, we’re level and still” and the other ear shouting “oh my God, we’re falling, we’re falling!!!” Visual stimuli can act as an intermediary, supporting one ear’s message or the other’s. Vertigo can also work in the opposite way, with the dizziness interfering with your vision.

I quickly found that when symptoms peaked, staring at a distant object would ease the falling sensation somewhat.

In the same fashion, some visual stimuli would worsen it.

Vertical slants were a big offender in that sense. For instance, looking at a subtle vertical slant (the kind that you’d have to look at twice to make sure it’s not perfectly vertical) on a webpage would instantly trigger symptoms for me. Whether it was a page-long slant used to create some interest beside text or a tiny decoration to mark active tabs, looking at anything with slight slants would instantly send me into the rollercoaster.

Horizontal slants (whatever the degree) and harder vertical slants wouldn’t cause these issues.

My best guess is that slight vertical slants can look like forced perspective and therefore reinforce the falling-from-height sensation, so I would recommend avoiding vertical slants if you can, or make them super obvious. A slight slant looks like perspective, a harder one looks like a triangle.

Target size matters (even on mouse-assisted devices)

After a magnetic resonance imaging (MRI) scan, some tests to discard neurological conditions, and other treatments that proved ineffective, I was prescribed Cinnarizine.

Cinnarizine is a calcium channel blocker—to put it simply, it prevents the malfunctioning inner ear “accelerometer” from sending incorrect info to the brain. 
And it worked wonders. After ten days of being barely able to get out of bed, I was finally getting something closer to my normal life. I would still feel dizzy all the time, with some peaks throughout the day, but for the most part, it was much easier.

At this point, I was finally able to use the computer (but still unable to produce any code at all). To make the best of it, I set on a mission to self-experiment on accessibility for vestibular disorders. In testing, I found that one of the first things that struck me was that I would always miss targets (links and buttons).

I’m from the generation that grew up with desktop computers, so using a mouse is second nature. The pointer is pretty much an extension of my mind, as it is for many who use it regularly. But while Cinnarizine helped with the dizziness, it has a common side effect of negatively impacting coordination and fine motor skills (it is recommended not to drive or operate machinery while under treatment). It was not a surprise when I realized it would be much harder to get the pointer to do what I intended.

The common behavior would be: moving the pointer past the link I intended to click, clicking before reaching it at all, or having to try multiple times to click on smaller targets.

Success Criterion 2.5.5 Target Size (Level AAA) of the World Wide Web Consortium (W3C)’s WCAG recommends bigger target sizes so users can activate them easily. The obvious reason for this is that it’s harder to pinpoint targets on smaller screens with coarser inputs (i.e., touchscreens of mobile devices). A fairly common practice for developers is to set bigger target sizes for smaller viewport widths (assuming that control challenges are only touch-related), while neglecting the issue on big screens expected to be used with mouse input. I know I’m guilty of that myself.

Instead of targeting this behavior for just smaller screen sizes, there are plenty of reasons to create larger target sizes on all devices: it will benefit users with limited vision (when text is scaled up accordingly and colors are of sufficient contrast), users with mobility impairments such as hand tremors, and of course, users with difficulty with fine motor skills.

Font size and spacing

Even while “enjoying” the ease of symptoms provided by the treatment, reading anything still proved to be a challenge for the following three weeks.

I was completely unable to use mobile devices while suffering vertigo due to the smaller font sizes and spacing, so I was forced to use my desktop computer for everything.

I can say I was experiencing something similar to users with mild forms of dyslexia or attention disorders: whenever I got to a website that didn’t follow good font styling, I would find myself reading the same line over and over again.

This proves once again that accessibility is intersectional: when we improve things for a particular purpose it usually benefits users with other challenges as well. I used to believe recommendations on font styles were mostly intended for the nearsighted and those who have dyslexia. Turns out they are also critical for those with vertigo, and even for those with some cognitive differences. At the end of the day, everybody benefits from better readability.

Some actions you can take to improve readability are:

• Keep line height to at least 1.5 times the font size (i.e., line-height: 1.5).
• Set the spacing between paragraphs to at least 2.0 times the font size. We can do this by adjusting the margins using relative units such as em.
• Letter spacing should be at least 0.12 times the font size. We can adjust this by using the letter-spacing CSS property, perhaps setting it in a relative unit.
• Make sure to have good contrast between text and its background.
• Keep font-weight at a reasonable level for the given font-family. Some fonts have thin strokes that make them harder to read. When using thinner fonts, try to improve contrast and font size accordingly, even more than what WCAG would suggest.
• Choose fonts that are easy to read. There has been a large and still inconclusive debate on which font styles are better for users, but one thing I can say for sure is that popular fonts (as in fonts that the user might be already familiar with) are generally the least challenging for users with reading issues.

WCAG recommendations on text are fairly clear and fortunately are the most commonly implemented of recommendations, but even they can still fall short sometimes. So, better to follow specific guides on accessible text and your best judgement. Passing automated tests does not guarantee actual accessibility.

Another issue on which my experience with vertigo proved to be similar to that of people with dyslexia and attention disorders was how hard it was for me to keep my attention in just one place. In that sense…

Animations are bad (and parallax is pure evil)

Val Head has already covered visually-triggered vestibular disorders in an outstanding article, so I would recommend giving it a good read if you haven’t already.

To summarize, animations can trigger nausea, dizziness, and headaches in some users, so we should use them purposely and responsibly.

While most animations did not trigger my symptoms, parallax scrolling did. I’d never been a fan of parallax to begin with, as I found it confusing. And when you’re experiencing vertigo, the issues introduced by parallax scrolling compound.

Really, there are no words to describe just how bad a simple parallax effect, scrolljacking, or even background-attachment: fixed would make me feel. I would rather jump on one of those 20-G centrifuges astronauts use than look at a website with parallax scrolling.

Every time I encountered it, I would put the bucket beside me to good use and be forced to lie in bed for hours as I felt the room spinning around me, and no meds could get me out of it. It was THAT bad.

Though normal animations did not trigger a reaction as severe, they still posed a big problem. The extreme, conscious, focused effort it took to read would make it such that anything moving on the screen would instantly break my focus, and force me to start the paragraph all over. And I mean anything.

I would constantly find myself reading a website only to have the typical collapsing navigation bar on scroll distract me just enough that I’d totally lose count of where I was at. Autoplaying carousels were so annoying I would delete them using dev tools as soon as they showed up. Background videos would make me get out of the website desperately.

Over time I started using mouse selection as a pointer; a visual indication of what I’d already read so I could get back to it whenever something distracted me. Then I tried custom stylesheets to disable transforms and animations whenever possible, but that also meant many websites having critical elements not appear at all, as they were implemented to start off-screen or otherwise invisible, and show up on scroll.

Of course, deleting stuff via dev tools or using custom stylesheets is not something we can expect 99.99% of our users to even know about.

So if anything, consider reducing animations to a minimum. Provide users with controls to turn off non-essential animations (WCAG 2.2.3 Animation from Interactions) and to pause, stop, or hide them (WCAG 2.2.2 Pause, Stop, Hide). Implement animations and transitions in such a way that if the user disables them, critical elements still display.

And be extra careful with parallax: my recommendation is to, at the very least, try limiting its use to the header (“hero”) only, and be mindful of getting a smooth, realistic parallax experience. My vertigo self would have said, “just don’t freaking use parallax. Never. EVER.” But I guess that might be a hard idea to sell to stakeholders and designers.

Also consider learning how to use the prefers-reduced-motion feature query. This is a newer addition to the specs (it’s part of the Media Queries Level 5 module , which is at an early Editor’s Draft stage) that allows authors to apply selective styling depending on whether the user has requested the system to minimize the use of animations. OS and browser support for it is still quite limited, but the day will come when we will set any moving thing inside a query for when the user has no-preference, blocking animations from those who choose reduce.

After about a week of wrestling websites to provide a static experience, I remembered something that would prove to be my biggest ally while the vertigo lasted:

Reader mode

Some browsers include a “reader mode” that strips the content from any styling choices, isolates it from any distraction, and provides a perfect WCAG compliant layout for the text to maximize readability.

It is extremely helpful to provide a clear and consistent reading experience throughout multiple websites, especially for users with any kind of reading impairment.

I have to confess: before experiencing my vestibular disorder, I had never used Reader Mode (the formal name varies in browsers) or even checked if my projects were compatible with it. I didn’t even think it was such a useful feature, as a quick search for “reader mode” actually returned quite a few threads by users asking how to disable it or how to take the button for it out of Firefox’s address bar. (It seems some people are unwittingly activating it…perhaps the icon is not clear enough.)

Displaying the button to access Reader Mode is toggled by browser heuristics, which are based on the use (or not) of semantic tags in a page’s HTML. Unfortunately this meant not all websites provided such a “luxury.”

I really wish I wouldn’t have to say this in 2019…but please, please use semantic tags. Correct conversational semantics allow your website to be displayed in Reader Mode, and provide a better experience for users of screen readers. Again, accessibility is intersectional.

Reader Mode proved to be extremely useful while my vertigo lasted. But there was something even better:

Dark color schemes

By the fourth week, I started feeling mostly fine. I opened Visual Studio Code to try to get back to work. In doing so, it served me well to find one more revelation: a light-text-on-dark-background scheme was SO much easier for me to read. (Though I still was not able to return to work at this time.)

I was quite surprised, as I had always preferred light mode with dark-text-on-light-background for reading, and dark mode, with light-text-on-dark for coding. I didn’t know at the time that I was suffering from photophobia (which is a sensitivity to light), which was one of the reasons I found it hard to read on my desktop and to use my mobile device at all.

As far as I know, photophobia is not a common symptom of vestibular disorders, but there are many conditions that will trigger it, so it’s worth looking into for our projects’ accessibility.

CSS is also planning a media query to switch color schemes. Known as prefers-color-scheme, it allows applying styles based on the user’s stated preference for dark or light theming. It’s also part of the Media Queries Level 5 spec, and at the time of writing this article it’s only available in Safari Technology Preview, with Mozilla planning to ship it in the upcoming Firefox 67. Luckily there’s a PostCSS plugin that allows us to use it in most modern browsers by turning prefers-color-schemequeries into color-index queries, which have much better support.

If PostCSS is not your cup of tea, or for whatever reason you cannot use that approach to automate switching color schemes to a user’s preference, try at least to provide a theming option in your app’s configuration. Theming has become extremely simple since the release of CSS Custom Properties, so implementing this sort of switch is relatively easy and will greatly benefit anyone experiencing photophobia.

Moving on

After a month and some days, the vertigo disappeared completely, and I was able to return to work without needing any meds or further treatment. It should stay that way, as for most people it’s a once-in-a-lifetime occurrence.

I went back to my abled life, but the experience changed my mindset for good.

As I said before, I always cared for making my projects compatible for people using keyboard navigation and screen readers. But I learned the hard way that there are plenty of “invisible conditions” that are just as important to take into consideration: vestibular disorders, cognitive differences, dyslexia, and color blindness, just to name a few. I was totally neglecting those most of the time, barely addressing the issues in order to pass automated tests, which means I was unintentionally annoying some users by making websites inaccessible to them.

After my experience with vertigo, I’ve turned to an accessibility-first approach to design and development. Now I ask myself, “am I leaving anyone behind with this decision?,” before dropping a single line of code. Accessibility should never be an afterthought.

Making sure my projects work from the start for those with difficulties also improves the experience for everyone else. Think about how improving text styles for users with dyslexia, vertigo, or visual problems improves readability for all users, or how being able to control animations or choose a color scheme can be critical for users with attention disorders and photophobia, respectively, while also a nice feature for everybody.

It also turned my workflow into a much smoother development experience, as addressing accessibility issues from the beginning can mean a slower start, but it’s also much easier and faster than trying to fix broken accessibility afterwards.

I hope that by sharing my personal experience with vertigo, I’ve illustrated how we can all design and develop a better web for everybody. Remember, we’re all just temporarily abled.

Late one night a few years ago, a panicked professor emailed me: “My transgender student’s legal name is showing on our online discussion board. How can I keep him from being outed to his classmates?” Short story: we couldn’t. The professor created an offline workaround with the student. Years later this problem persists not just in campus systems, but in many systems we use every day.

To anyone who’d call that an unusual situation, it’s not. We are all already designing for trans users—1 in 250 people in the US identifies as transgender or gender non-binary (based on current estimates), and the number is rising.

We are web professionals; we can do better than an offline workaround. The choices we make impact the online and offline experiences of real people who are trans, non-binary, or gender-variant—choices that can affirm or exclude, uplift or annoy, help or harm.

The rest of this article assumes you agree with the concept that trans people are human beings who deserve dignity, respect, and care. If you are seeking a primer on trans-related vocabulary and concepts, please read up and come back later.

I’m going to cover issues touching on content, images, forms, databases, IA, privacy, and AI—just enough to get you thinking about the decisions you make every day and some specific ideas to get you started.

“Tried making a Bitmoji again, but I always get disillusioned immediately by their binary gender model from literally step 1 and end up not using it. I don’t feel represented.”

Editorial note: All personal statements quoted in this article have been graciously shared with the express consent of the original authors.

How we can get things right

Gender is expansively misconstrued as some interchangeable term for anatomical features. Unlike the constellation of human biological forms (our sex), gender is culturally constructed and varies depending on where you are in the world. It has its own diversity.

Asking for gender when it is not needed; limiting the gender options users can select; assuming things about users based on gender; or simply excluding folks from our designs are all ways we reify the man-woman gender binary in design decisions.

Names are fundamentally important

If we do nothing else, we must get names right. Names are the difference between past and present, invalidation and affirmation, and sometimes safety and danger.

Yet, many of the systems we use and create don’t offer name flexibility.

Many programmers and designers have a few misconceptions about names, such as assuming people have one moniker that they go by all the time, despite how common it is for names to change over a lifetime. People might update them after a change in marital status, family situation, or gender, or perhaps someone is known by a nickname, westernized name, or variation on a first name.

In most locales, legally changing names is extremely difficult, extremely expensive, requires medical documentation, or is completely out of the question.

Changes to name and gender marker are even more complicated; they tend to be two separate, long-drawn-out processes. To make matters worse, laws vary from state to state within the U.S. and most only recognize two genders—man and woman—rather than allowing non-binary options.Not all trans people change their names, but for those who do, it’s a serious and significant decision that shouldn’t be sabotaged. We can design systems that protect the lives and privacy of our users, respect the fluid nature of personal identity, and act as an electronic curb cut that helps everyone in the process.

Deadnaming

One need only search Twitter for “deadname app” to get an idea of how apps can leave users in the lurch. Some of the most alarming examples involve apps and sites that facilitate real-life interactions (which already involve a measure of risk for everyone).

“Lyft made it completely impossible for me to change my name on its app even when it was legally changed. I reached out to their support multiple times and attempted to delete the account and start over with no result. I was completely dependent on this service for groceries, appointments, and work, and was emotionally exhausted every single time I needed a ride. I ended up redownloading Uber - even though there was a strike against the service - which I felt awful doing. But Uber allowed me to change my name without any hoops to jump through, so for the sake of my mental health, I had to.”

Trans people are more likely to experience financial hardship, so using payment apps to ask for donations is often necessary. Some of these services may reveal private information as a matter of course, leaving them exposed and potentially at risk.

There are also ramifications when linked services rely on our data sources for name information, instigating an unpredictable cascade effect with little or no recourse to prevent the sharing of sensitive details.

These are examples of deadnaming. Deadnaming is what happens when someone’s previous or birth name is used, rather than the name the person uses now. Deadnaming is invalidating at the least, even as a faux pas, but can be psychologically devastating at the other extreme, even putting lives at risk.The experiences of trans, non-binary, or gender-variant folk can vary widely, and they live in disparate conditions throughout the world. Many are thriving and creating new and joyful ways to resist and undo gender norms, despite the common negative narrative around trans lives. Others can face hardship; trans people are more likely to be unstably housed, underemployed, underpaid, and targets of violence in and out of their homes, workplaces, and intimate relationships. The ramifications are amplified for people of color and those with disabilities, as well as those in precarious living/working situations and environments where exposure can put them in harm’s way.

Design for name changes

Here’s what we can do:

Design for renaming. Emma Humphries’ talk on renaming covers this nicely. Airbnb has developed policies and procedures for users who’ve transitioned, allowing users to keep their review histories intact with amended names and/or pronouns.

Get rid of “real name” requirements. Allow people to use names they go by rather than their legal first names.

Clarify when you actually need a legal name, and only use that in conjunction with a display name field.

Have a name change process that allows users to change their names without legal documentation. (It’s likely that you have procedures for marriage-related name changes already.)

Ensure users can still change their display names when connecting with other data sources to populate users’ names.

Don’t place onerous restrictions on changes. Once someone creates a username, web address, or profile URL, allow them to change it.

Draft a code of conduct if you’re part of an online community, and make sure to include policies around deadnaming. Twitter banned deadnaming last year.

Allow people to be forgotten. When people delete their accounts for whatever reason, help them make sure that their data is not lingering in your systems or in other places online.

Update the systems users don’t see, too

Identity management systems can be a mess, and name changes can reveal the failures among those systems, including hidden systems that users don’t see.

One Twitter user’s health insurance company kept their ID number between jobs but changed their gender. Another user updated their display name but got an email confirmation addressed to their legal name.

Hidden information can also undermine job opportunities:

“At a university as a student, I transitioned and changed my name and gender to be a woman. TWELVE YEARS later after being hired to work in the Libraries, the Libraries HR coordinator emailed me that I was listed as male still in the database. He changed it on my asking, but I have to wonder how long… was it a factor in my being turned down for jobs I applied to… who had seen that..?”

Emma Humphries details the hidden systems that can carry out-of-date information about users. Her tips for database design include:

• Don’t use emails as unique IDs.
• Use an invariant user ID internally, and link the user’s current email and display name to it.

Images

Visuals should allow room for representation and imagination rather than a narrow subset of the usual suspects: figures who appear to be straight, cisgender, able-bodied, and white/Caucasian.

What we can do is feature a variety of gender presentations, as well as not assume someone’s gender identity if they buy certain items.

Some companies, like Wildfang and Thinx, offer a broad array of images representing different races, body sizes, and gender expressions on their websites and in their ads.

Many are also choosing not to hire models, allowing room for imagination and versatility:

“I got a catalog for a ‘classic menswear company’ that features zero photos of any person of any gender. Now if only I could afford an $800 blazer...”

Here's what we can do:

Actively recruit diverse groups of models for photos. And pay them!

If you can’t shoot your own photos, Broadly has recently launched a trans-inclusive stock photo collection free for wide use. Avataaars allows users to create an avatar without selecting a gender.

Information architecture

How we organize information is a political act and a non-neutral decision (librarians have said this for a while). This applies to gender-based classifications.

Many companies that sell consumer goods incorporate gender into their product design and marketing, no matter what. The product itself might be inherently gender-neutral (such as clothing, toys, bikes, or even wine), but these design and marketing decisions can directly impact the information architecture of websites.

Here's what we can do:

Evaluate why any menus, categories, or tags are based on gender, and how it can be done differently:

“Nike has a ‘gender neutral’ clothing category, yet it’s listed under ‘men’ and ‘women’ in the website architecture. ????”

Forms

Forms, surveys, and other types of data gathering are surefire ways to include or exclude people. If you ask for information you don’t need or limit the options that people can select, you risk losing them as users.

Here's what we can do:

Critically evaluate why you are asking for personal information, including gender. Will that information be used to help someone, or sell things to your advertisers?

"Why does the @CocaCola site make me select a gender just to make a purchase? Guess my family isn't getting personalized Coke bottles for Christmas."

If you are asking users for their gender, you’d better have a good reason and options that include everyone. A gender field should have more than two options, or should ask for pronouns instead. When including more than binary options, actually record the selections in your databases instead of reclassifying answers as male/female/null, otherwise you risk losing trust when disingenuous design decisions become public.

Honorifics are infrequently used these days, but it takes little work to add gender-inclusive titles to a list. For English-language sites, “Mx.” can go alongside “Mr.” and “Ms.” without fuss. United Airlines debuted this option earlier this year.

Content

Here's what we can do:

Avoid inappropriately gendered language. Your style guide should include singular “they” instead of “he/she” or “s/he,” and exclude frequently used words and phrases that exclude trans folks. Resources such as this transgender style guide are a quick way to check your language and benchmark your own content guidelines.

Check assumptions about gender and biology. Not everyone who can have a period, can get pregnant, or can breastfeed identifies as women or mothers—just as not everyone who identifies as women or mothers can have periods, can get pregnant, or can breastfeed. Thinx, a company that sells period underwear, has an inclusive tagline: “For people with periods.”

Avoid reinforcing the binary. Groups of people aren’t “ladies and gentlemen” or “boys and girls.” They are folks, people, colleagues, “y’all,” or even “all y’all.”

Pronouns aren’t “preferred”—they’re just pronouns. Calling pronouns preferred suggests that they’re optional and are replacing a “true” pronoun.

Avoid reinforcing stereotypes about trans people. Not all trans people are interested in medically transitioning, or in “passing.” They also aren’t fragile or in need of a savior. Gender is separate from sexual orientation. You can’t “tell” someone is trans.

Privacy, surveillance, and nefarious AI

We’ve heard the story of algorithms identifying a pregnant teen before her parents knew. What if an algorithm predicts or reveals information about your gender identity?

Inferences. Users’ genders are assumed based on their purchase/browsing history.

Recommendations. A user bought something before they transitioned and it shows up in “recommended because you bought X.”

Predictions. Users’ genders are not only inferred but used to predict something else based on characteristics of that gender. Even if you don’t tell big websites what your gender is, they assume one for you based on your interests. That kind of reductive essentialism can harm people of all genders. One of this article’s peer readers summed this up:

“Gender markers are a poor proxy for tastes. I like dresses, cute flats, and Raspberry Pis.”

Flashbacks. “On this day” algorithms remind users of the past, sometimes for better (“I’ve come so far”) or for worse (“don’t remind me”).

AI-based discrimination

AI and surveillance software can also reinforce norms about what men’s and women’s bodies should look like, resulting in harrowing airline travel experiences and creating AI-based discrimination for trans people.

So, too, can trans folks’ public data be used for projects that they don’t consent to. Just because we can use AI for something—like determining gender based on a face scan—doesn’t mean we should.

Here's what we can do:

Read up and proactively mitigate bias. AI and algorithms can reflect developers’ biases and perpetuate stereotypes about how people’s bodies should look. Use AI to challenge the gender binary rather than reinforce it. Design for privacy first. Hire more types of people who represent different lived experiences.

Toward a gender-inclusive web

The ideas I’ve offered here are only starting points. How you choose to create space for trans folks is going to be up to you. I don’t have all the solutions here, and there is no singular trans experience. Also, language, definitions, and concepts change rapidly.

We shouldn’t use any of these facts as excuses to keep us from trying.

When we start to think about design impact on trans folks, the ideas we bring into question can benefit everyone. Our designs should go beyond including—they should affirm and validate. Ideally, they will also reflect organizational cultures that support diversity and inclusion.

Here's what we can do:

Keep learning. Learn how to be a good ally. Pay trans user research participants to help validate your design assumptions. Hire trans people on your team and don't hang them out to dry or make them do all the hard work around inclusion and equity. Make it everyone’s job to build a more just web and world for everybody.

Editorial note: All personal statements quoted in this article have been graciously shared with the express consent of the original authors.

This article is stronger and wiser thanks to Mica McPheeters at A List Apart and the following peer readers. Thank you.

Jake Atchison
Katherine Deibel, Ph.D.
Justina F. Hall
Austyn Higgs
Emma Humphries
Tara Robertson
Levi R. Walter

Dewey Library - HB523.R84 2019

Dewey Library - HC120.E5 O45 2019

Dewey Library - HB501.B76 2019

Online Resource

Online Resource

Dewey Library - HB3654.A3 M3613 2019

Online Resource

Dewey Library - HC59.7.B3355 2019

Dewey Library - HC440.5.N43 2019

Dewey Library - HC79.T4 S875 2019

Online Resource

Dewey Library - HB801.T5285 2019

Online Resource

Dewey Library - HC79.E5 L5625 2019

Online Resource

Online Resource

Online Resource

Online Resource

Dewey Library - HC37.S55 2018

Dewey Library - HB883.5.D37 2019

Dewey Library - HC79.I5 S787 2019

Online Resource

Dewey Library - HC79.I5 O85 2019

Dewey Library - HB615.H95 2018

Online Resource

Dewey Library - HC412.N39 2019

Dewey Library - HC260.P6 K56 2019

Online Resource

Online Resource

Southern Methodist University

River Indus

University of Waterloo

Humboldt State University