Practical Steps To Build Transparency In Your Remote Business

 Transparency is part of the fabric of many remote businesses. It doesn’t, however, come naturally to everyone, especially if you’ve only recently become remote. In this article, Siobhan takes you through some of the practical ways that you can build transparency within your organization.

It used to be the norm that businesses were opaque, with employees only having access to what they needed to get their work done. Over the past twenty years, though, there has been an increase in transparency in businesses: an article in HBR describes transparency as a leadership imperative, and studies conducted by companies like Slack and Tinypulse highlight the importance of transparency to employees.

“Transparency is the process of being open, honest, and straightforward about various company operations. Transparent companies share information relating to performance, small business revenue, internal processes, sourcing, pricing, and business values.”

— Forbes

Companies can be transparent with their employees only; others take it further and are transparent with the world. In a remote organization, transparency is even more critical. When you rarely see your colleagues, transparency helps people feel connected to one another and to the business. It can also help to reduce timezone bias as it relies on asynchronous communication, which makes it easier for people at any timezone to participate.

In this article, I will share some tactics for improving transparency within your organization. Some of them are tactics I’ve implemented myself through my years as a remote worker and leading a remote company, and others are best practices and guidance shared by companies leading the pack in terms of remote work.

Tactics To Improve Transparency

Default To Open

Imagine signing in to your company’s Slack team, where little of the day-to-day work happens in public channels. Some people say hi in the morning or goodbye in the evening, but all the work happens in private channels and DMs. The #general channel is a dead zone. Work happens in silos, and it’s hard to know what is going on at any one time. Individuals have to ask for information when needed, and sometimes they don’t even know where to look. This can cause bottlenecks and slow down work.

At the opposite end of the spectrum is a remote team where everything is in the open: hundreds of channels cover the whole range of work done in the company, and personal interests are chucked in too. Just by looking at the list of channels in your work’s messaging platform, you’ll see the overall work and identity of the company, and anyone can jump into any channel and connect with what’s going on there. It makes people feel more connected to work across the company rather than restricting people to work silos. It also has the advantage of exposing questions and discussions to more people. You never know who might have the answer to your question, and by posting it in public, someone you wouldn’t expect might be able to help.

Practical Tips

• Onboard new employees on how to work in the open through their onboarding period and gently nudge them to post questions and work discussions in public channels.
• Create naming conventions for your teams’ channels because you will end up with a lot, and it helps with the organization if people can see them grouped together (e.g., #marketing-content, #marketing-design, #dev-qa, and so on).
• Remember that some things that shouldn’t be public. Human Resources matters such as illness or performance and anything that is a special category data under GDPR should not be shared by the company. You can, however, be transparent about what won’t be open.
  
  

Lean In To Asynchronous Communication

Synchronous communication happens in real time, whether that’s on a video or voice call, messaging, teams, or in person. Asynchronous communication happens in your own time, and immediate responses are not requested or expected within the exchange.

There are many reasons why asynchronous communication is beneficial in a remote company:

• Reduces roadblocks as employees don’t need to be online at the same time;
• Increases flexibility for employees as they can prioritize when to respond;
• Combats presenteeism;
• Demonstrates trust in employees;
• Reduces timezone bias;
• Increases transparency as it relies on written communication and documentation.

Prioritizing asynchronous communication over synchronous communication doesn’t mean that you will never have a meeting or talk at the same time. Instead, it means that your first preference is tools such as documentation and shared issue trackers/task managers instead of having a call. Documentation is kept up to date so people can find what they need for themselves, and issue trackers capture what someone is doing and where they are at and provide spaces for collaboration that don’t require everyone to be online at the same time. By preferring these practices over synchronous practices, work carried out within the organization is always transparent and available.

Practical Tips

• Choose a tool that people love to use that they can use to keep track of their work. There are so many project management tools that you should be able to find one that suits your way of working.
• Keep your issue tracker updated with all of the most up-to-date information about where a task or project is, including links to works in progress, such as Google Docs, Slides, and spreadsheets.
• Create guidelines and onboard people to this way of working. Don’t just assume that people know how to work asynchronously. If they are from a traditional office, it’s unlikely that they will.
• Encourage everyone to ask, “do I need a meeting for this?” and make working in other spaces the default. This ensures full transparency of what’s happening, and people can engage in their own time.
• Make sure that decisions are documented so that everyone knows what action to take and why.

Document Processes And Continuously Improve

Effective remote companies need to have great documentation. This is especially true as companies grow. When you’re a small number of people, with just a handful of people in each role, it can feel easier just to get on and do the work and not worry about documentation.

Without embedded, documented practices, different approaches to the same task will proliferate, and it will become difficult to know what is the }}best approach for the organization as a whole}}. The growth that is not managed leads to inefficiencies within the business because things spin up in new ways all the time. When new employees join, they are unclear about whose approach is the right approach, and interpersonal issues may surface just because people disagree about the best way to do things.

Good documentation creates a shared expectation about how things should be done. A well-documented process should be a ladder rather than a cage. It should provide you with the steps to get to where you want to go, which you might need to adapt to your specific circumstance rather than being something fixed that you have to stick to rigidly.

For documentation to be useful, it has to be kept up-to-date. Out-of-date documentation is worse than no documentation at all, as it tells you the wrong way to go about doing something. Therefore, I advocate keeping documentation as straightforward and to the point as possible — only enough information so that a reader can achieve their goals. Anything else is just maintenance overhead that you don’t need.

Employees shouldn’t need to jump on a call for a walkthrough, ping lots of different people to find out what they need, or be confused by the different ways that they are told to do something. This is essential to enable everyone to work autonomously and reduce time wasted on calls because something isn’t written down.

Practical Tips

• Ensure that your documentation tool has everything you need to ensure that people can navigate and update it easily. We find built-in version control essential to see what has changed (spoiler: we use WordPress for documentation).
• Add dates to your documentation, so people know when it was written. If you want to embed practices of continuous improvement, you can add expiry dates to your documents, and process owners are expected to review and complete any updates.
• Provide clear expectations around documentation. If a process exists, it must be documented.
• Gitlab sets the standard with their “handbook-first” approach. It’s worth reading how they approach documentation and adapting what is useful to your own context.

Manage The Noise

An advantage of transparency is that information is there to be found. However, there needs to be the correct systems and processes in place so that people can find them. As someone from a company that has been remote for 10+ years, I’m amazed at the amount of documentation and communication that has built up over the years, not to mention the proliferation of tools. If you’re early in your remote journey, I highly recommend creating structures now that will enable you to keep on top of all the comms as you grow.

You need to proactively manage your docs and tools. It’s like a garden: you plant flowers in the flower beds, maybe a few trees and shrubs, and get your lawn looking lovely. But over time, the weeds start to appear, the shrubs become overgrown, and the flowers need to be dead-headed.

Transparency can have a positive impact on your company, but if you don’t tend to your documentation and information, it can end up being like an overgrown garden, where you have to clamber through weeds to get what you want or find a path through it.

Practical Tips

• Create onboarding pathways for different roles so that when new people join the company, they know where to find what they need and are taken through it step by step.
• Stay on top of your information architecture and make sure it remains intuitive for employees. Ideally, keep your IA the same or similar across your different tools (e.g., GDrive for docs, handbooks, and so on).
• Often, people will just search for what they need to make sure that you have a working search tool.
• Set expectations about what people need to stay on top of. It’s important that people are up-to-date on what’s happening in their areas, but do they need to read every piece of communication?
• Create an announcements channel or blog, with the expectation that the only items posted are things that everyone has to read. This makes sure that nothing important gets missed.
  

Record Meetings And Provide Useful Notes #

Preferencing asynchronous communication doesn’t mean ever communicating synchronously. There are times when meetings are inevitable and valuable. However, that doesn’t mean that what happens in the meeting needs to stay within the black box of that meeting. We have tools at our disposal to make these transparent, but as with all things, we want these to be as frictionless as possible.

Recording a meeting so that anyone who is not present can catch up on it can be helpful. Also, this reduces the need for detailed minutes as anyone who wants specific details can watch the recording or catch up on the transcript (zoom has built-in transcription features, which provide a good enough transcript to scan what’s going on). This may not be suitable for all meetings as it can have a knock-on effect on people’s behavior, making them more guarded.

Alongside that, there are the meeting notes. There are as many different ways of producing notes as there are people writing them. You need to determine the purpose of your notes to put them in the best format for your organization. When thinking about it, ask yourself what someone who hasn’t attended the meeting needs to know. If a video is available, do they need full minutes or just notes about decisions, actions, and deadlines? Who is going to take the notes? Are they always taken by a specific person, or is it a role that rotates?

Practical Tips #

• Always have an agenda for a meeting and ensure that anyone who adds an item to the agenda also writes a summary with links to supporting documentation. This provides the basis for the notes and means the note taker doesn’t have to re-summarise.
• Make sure everyone knows what the expectations are around meeting notes. A standard meeting template means that everyone knows what they need to provide before and during the meeting and that everyone reading notes knows what to look for.
• Ask yourself if you need notes every time. Maybe a video suffices for a discussion, especially if all of your actions are captured in your issue tracker. Maybe it’s enough just to keep an activity log, so everyone stays on top of what’s next.

Onboard New Team Members To Transparency

Something I have been guilty of is assuming that people will just be able to join the company and instantly normalize how transparent we are. Actually, it’s quite challenging for someone to go from an organization that is not transparent or doesn’t really think about it to one in which everything is out in the open.

It requires some empathy and imagination to recognize the experience of someone who has just joined the company. As there is a lot of noise, communication, and notifications, there is a mountain of information to climb and years of asynchronous communication stacked up. On top of that is the feeling of vulnerability that comes with being a new employee. When the expectation is that everything is discussed in public channels, it can make people feel reticent about putting themselves out there, asking the “stupid” questions that are so important to navigating your way around somewhere new.

That makes it essential to familiarise people with the concepts and tactics of transparency through the onboarding process and for managers and peers to support new starters with that. You can’t just assume someone will get it, so you need to support them to succeed.

Practical Tips

• Have clear expectations about what people should read and what they can let pass them by. Otherwise, some people will try to read everything. For most people, the work of their immediate team and essential company announcements suffice to begin with.
• Talk about transparency through the onboarding process, why it is important, and how you practice it within your company.
• Adjust to your new employee’s level of comfort. Some people will jump straight into public channels, but others will want to take their time. Work with them in DMs or private channels to begin, with the expectation that you’ll move to the public once they are onboarded.
• Create specific pathways or tables of contents for different roles to take them through the documentation and training they need to read.
• Provide guides and documentation on how to practice transparency, especially best practices for documentation and for using your issue tracker.

Make Use Of Integrations, APIs And Bots

Integrations, APIs, and Bots let us automate work and prevent information from getting stuck in silos. One of the first things I look for when I’m sourcing a new tool is what integrations it has and whether it will integrate with my stack. If it doesn’t have a native integration, does it have an API so we can have a developer build an integration for us? Or, for simple integration, you can use a tool like Zapier to connect your tools together.

However, if you don’t transfer your data, it can lead to information remaining in silos and not getting to where it needs to be. If you are building out a stack for your remote team, I highly recommend working with tools and apps that integrate with one another.

As well as integrations, bots can be massively helpful in automating tasks and removing the need for people to manually run different processes. Some tools that I have found to be useful are geekbot, which we use for standups, and donut, which we use for social connections like pairing people up for a coffee. You can use integrations to pipe posts from other tools, such as GitHub or Hubspot, into your Slack Channel or MS Teams. Geekbot fatigue is real, though, so beware of having too many standups and bots running simultaneously because if they’re not used well, they can become a bureaucratic task that no one loves.

Practical Tips

• Figure out the bots which are right for your organization. Both Slack and Teams have a lot of bots available.
• When you are signing up for a new tool, look at the integrations that it currently has and think about how you might want to use the tool in the future.
• Connect your issue tracker and any other asynchronous tools to your messaging app so that any activity is piped into relevant channels.
• If bots are causing too much noise, consider creating firehose channels, which are just for piping in information from a specific tool or project.

Equip Everyone To Give And Receive Feedback

When your company is transparent, everything is out in the open all of the time. This means that a culture of transparency must go hand in hand with a culture of feedback. Drive-by feedback from people who don’t have context on a specific project is rarely helpful, nor are cryptic one-liners that say something isn’t great but don’t provide anything constructive about why.

This type of feedback can make people reticent about working in the open, and they can hold things back until they feel it is totally ready. Equally unhelpful are feedback requests that are just “what do you think?” or “can I have feedback?” These requests rarely elicit high-quality feedback.

When you equip your team to give feedback, you create a space where people are okay putting their half-finished projects out there because they know any feedback will be provided in good faith and will help them to achieve their goals. You also need to ensure that people are open to feedback, listen, and receive it in a non-defensive manner. Ultimately, it is up to the person who receives the feedback whether they should implement it or not, but you should always listen and try to understand the other person’s perspective.

Practical Tips

• Set company-wide expectations around feedback. Some companies might prefer a free-for-all where anyone can provide feedback all the time; others prefer to set the expectation that feedback should come only when it is asked for.
• Be very specific on what you are asking for feedback for: is it on the design, the content, the tone of voice, the structure, or the message? This will help you to get high-quality feedback.
• Research different feedback methodologies and adopt a few that are right for your company. Radical Candor is a very popular technique; I like Situation, Behaviour, Impact because of its simplicity, but there are lots of options out there. Whatever you use should be straightforward enough for anyone to use.

Build A Culture Of Transparency

You can build transparency into your practices, but you also need to build it into your culture. A common way to do this is to write transparency into your values, which is great but rarely enough. You’ve got to embed transparency into everything you do, which I hope some of the practices above will help with.

One of the most powerful ways to become more transparent as a company is for people to role-model transparency, especially leaders. If a leader behaves in a particular way, others follow. It follows that if someone at the top does something, then it is acceptable behavior.

If a leader does everything in Direct Messages, brings people into meetings all the time, and works in silos, then others will do the same. If your leaders default to open communications, asynchronous practices, collaboration, and information sharing, then they create an environment where others will follow.

And remember, full transparency isn’t for everyone or for every company. You can set limits on what you are transparent about: some organizations share salaries, others don’t, some share financial info, others don’t, some share everything publicly, and others don’t. Being transparent isn’t necessarily sharing everything; it’s being upfront about what you are going to share, what you aren’t, and why. But remember that some level of transparency in a remote organization will go a long way to helping you be successful.

Practical Tips

• Role-modelling transparent behaviors should be built into the expectations of every leader. This could be written into role descriptions or behavior frameworks.
• It’s easy to find yourself working on something in a DM or private space; when you do, gently suggest to others that a discussion is moved into a public channel.
• Acknowledge behavior and actions that are transparent. We have a kudos bot in our HRS which we can use to credit positive behavior, and transparency is a consideration within our career progression framework.

The Transparency Trap?

Generally, I am a big advocate of transparency, but it’s not without its pitfalls. If you want your organization to be more transparent, then you need to be aware of what these are so that you can work against them. Some examples are:

• Decision-making can take a lot longer because so many people can provide input.
• Information overload can be a burden on employees, and they can feel fatigued by the amount of communication.
• Employees can feel that they are constantly being observed, which can leave them feeling exposed and vulnerable.
• Some employees will hide what they are doing just to get it right, even if there is nothing to hide.
• People experiment less because they are afraid to take risks or be vulnerable in front of others.
• There is an additional administrative burden as people have to produce meeting notes, update documentation and issue trackers, and generally perform what they are doing.
• Access to a company’s financial information can cause anxiety when times are rocky.
• Creative work may not always benefit from transparency as people can self-censor during the development process.
• Sharing all meetings can lead to self-censorship, which can stifle debate.

The researcher Ethan Bernstein talks about the “transparency trap” and explains how some organizations have “found the sweet spot between privacy and transparency, getting the benefits of both.” This means employing different types of boundaries to ensure that privacy is maintained in some areas without losing the benefits of transparency. However transparent you plan to be, it’s important to keep these challenges in mind so that you can work and don’t overwhelm or undermine your employees while still getting all of the benefits of transparency.

Smashing Podcast Episode 54 With Stéphanie Walter: What Is User Journey Mapping?

 In this episode we’re talking about User Journey Mapping. What is it, and how does it help us build better digital products? Vitaly talks to expert Stéphanie Walter to find out.

This article has been kindly supported by our dear friends at Deque who help us all make websites and mobile apps accessible. Thank you!

In this episode we’re talking about User Journey Mapping. What is it, and how does it help us build better digital products? Vitaly talks to expert Stéphanie Walter to find out.

Show Notes #

• Stéphanie Walter on LinkedIn and Twitter
• Stéphanie’s homepage

Weekly Update #

• What’s New In Next.js 13? written by Atila Fassina
• How To Search For A Developer Job Abroad written by Andrew Stetsenko
• A Guide To Keyboard Accessibility: HTML And CSS (Part 1) written by Cristian Diaz
• Using Automated Test Results To Improve Accessibility written by Noah Mashni and Mark Steadman
• A Guide To Image Optimization On Jamstack Sites written by Alba Silvente

Transcript #

Vitaly Friedman: She’s a UX expert, researcher and product designer with expertise in design and strategy. She lives in Luxembourg, teaches at school and universities and facilitates workshops in small and large teams, not a day passes by without Stephanie sharing what she has learned on Twitter on LinkedIn, and in her wonderful weekly roundup called the Pixels of the Week. She recently wrote a book on user journey maps and currently works for MAL consulting and European Investment Bank all around enterprise UX challenges. So we know she’s a fantastic designer and problem solver, but did you know that she once had a full 45 minutes long conference talk on pizza recipe examples. If your favorite pizza surprise, surprise is a vegetarian one, but with added bacon or ham. My smashing friends, please welcome Stephanie Walter. Hello Stephanie. How are you doing today?

Stéphanie Walter: Yay, I’m smashing. And it’s Friday. So yeah.

Vitaly: Yay. It’s Friday. Does Friday usually mean pizza day for you?

Stéphanie: Yeah, pizza or Indian food as well.

Vitaly: Okay, that sounds wonderful. Well, Stephanie, it’s always such a pleasure to see you. I know that you spoke at the Smashing Cup Barcelona, I think a while back. It feels like it was, yeah, I don’t know, 150 years ago. So I always learned so much from you. So maybe it’s a good idea to start by just asking you to share a little bit of your story. So how did you even end up getting into this? I know that much of your time is spent around Enterprise UX, but eventually you had to go through a lot of different things and I know you did a lot of different things throughout your career to get there. So maybe share a little bit about your background and your story.

Stéphanie: So I have a master degree in design and languages. It’s a little bit strange. It’s both. It’s a degree where you learn how to build website and how to translate them basically. And after that I decided to do an internship in Germany. So I was working for a company and I think I finished what I was supposed to do in three months instead of six. So they said, hey, do you want to do mobile apps? I was like, yeah, I’ve never done that, but sure. So I got interested and at the time there was not a lot of documentation on mobile and native design, but there was something on Apple guideline and it was called Human Computer Interaction, something like that. So it kind of drove me into HCI and UX design. So we had usability class at the university. We had kind of a few hours of how do you do usability tests, but that was basically it.

Stéphanie: And then during my internship I discovered UX design. I thought like, oh, this is actually what I want to do. It’s quite interesting, understanding user needs and really building products and services that try to fit and match those needs. So I worked in Germany, then I went back to France to work for a web agency and I said, yeah, if I’m going to leave the agency, I’m going to leave France. So this is basically what I did. And I got hired at the University of Luxembourg as a researcher assistant in the Human Computer Interaction Department. So it was very interesting to work in an academic place. And after that I decided to go back to private sector, and I was lucky I worked with a company that had a lot of different contracts in a lot of different areas, and this is really when I started specializing in Enterprise UX because they were doing a lot of things that were either B2B or B2B to C, but it was always ugly complex dashboards and a lot.

Vitaly: This sounds exciting stuff, isn’t it?

Stéphanie: Yeah, I remember I had to help with the design of a form that was for Luxembourgish customs, and the form was so complicated in terms of levels that I printed it on a piece of paper and I just drew lines to understand the hierarchy and information architecture of that. And it’s a little bit complicated because it’s like you have to have a number and all the numbers stacks up. So if you have the tax number, every single digit means something. So it’s like apples that were harvest between October and November in specific countries in Europe that are designed to become cider, all of that, it’s a number.

Vitaly: Well that does sound like a very exciting exercise in design.

Stéphanie: Crazily complex. But I have eight levels, we have six levels in html, H1, 2, 3, 4, 5, 6. What do we do?

Vitaly: But then look at that, you have established itself as an expert in helping other people harvest apples, but instead of decided to jump more into design and UX work.

Stéphanie: So it was a lot of different really, really cool stuff around that. And I was like, yeah, you know what? I’m never going to be a fancy designer, like those designer who do amazing website for marketing campaigns or I don’t know, I know a lot of people who do really cool stuff around the museum and things like very immersive. I was like, yay. I like complex challenging, super heavy information architecture and solving problems for people who have to work with a tool on a daily basis. And I was like, okay, I think this is kind of the kind of challenge that I like and I want to keep on working on that.

Vitaly: That’s interesting. So it’s always kind of fascinating story to me because I think that we have a lot of articles about designing a perfect button and picking the right icons and making responsive tables and navigation, things like that. But when I dive deep into this really, really complicated world of enterprise applications or multi-level like six, seven levels of navigation and I don’t know, 20, 25 multi form pages with PDFs integrated and all of that, I’m wondering, I mean I know that this is your life, most part of it. I’m wondering at this point, do you think that the world in which we’re living in, the enterprise world, is undiscovered? Are there a lot of books, articles, resources on that? How do you feel in that world?

Stéphanie: Honestly, there’s not a lot of content that specifically talked to that. And I don’t know why. Maybe because NDAs and things like, that’s a lot of stuff that you can’t show in those areas. Also, let’s face it’s not fancy. No one wants to see an interface that is supposed to help you optimize track driving through the area or something super complicated. So it’s not self explanatory. So a lot of people, they don’t put those on the portfolios because today there’s still this idea that you need some wow stuff in the portfolio. So I think there’s a lot of people around here that actually work in enterprise UX with complex software like that, but there’s not a lot of content about it. But why is a mystery to me.

Vitaly: Well, you are changing that. I think in many ways it’s just the fact that what really surprises me really is that we see a lot of case studies about portfolio designs, about immersive campaigns, like you mentioned, things related to branding, I don’t know, big redesigns that happen in big companies and so on. But not necessarily about those things, which are, I don’t know, insurance companies and truck configurators and whatnot. So that’s kind of always challenging for me. But I also want to ask you maybe on another side of that, when you think about enterprise UX, I think that many of us listening this later or in years from now, maybe still will be thinking about long meetings, long deadlines, complex workflows, a lot of legacy. Is that enterprise UX or how would you describe it? How would you define it?

Stéphanie: It necessarily depends. You can arrive on a project where they have nothing and then there’s no legacy. You build from the ground, but you still have a lot of meeting because the business is complex. So you need time to understand the business. You also need help to, you can’t really go around those meetings because they are usually kind of useful to help you understand exactly what is going on. But then, yeah, it depends. Legacy is one problem. Another problem that I see and foresee in the future is depending on when we are those Gartner, Bloomberg and all of those big company, they either tell people that they need to internalize the team and then you need to do in-house developments. So you have a bunch of developer who will develop the enterprise, product often without designers.

Stéphanie: And then a few years later, Gartner goes like, no, you know what, no. Package the new thing. So stop having an internal IT team, buy packages, and then everyone decides to buy package. And then there’s a new wave from, I don’t know, Gartner, Bloom, whatever, Harvard Business Review, those people that big company listen to. And they say, yeah, no, let’s go hybrid, let’s do something like a package. But then the package is the business web services, and then you can still do the UI, the front ends. So this cycling through, and it’s really, really funny because if you worked in such industry for a few years, you’ve seen the waves of Oh, let’s build everything internally. Oh, let’s build a package. But look, the business is so complicated. We bought a package and now we discover doesn’t fit our need. I think we need to rebuild something internally and then, but building things internally costs a lot of money. So let’s package. It’s kind of every few years it comes around.

Vitaly: I think it’s also related to the fact that there is just a lot of layers and with every layer comes a bit of politics involved and everybody has their own interests and KPIs and goals. And I’m wondering how do you even operate in this kind of environment? I mean, you must have very strong governance, very strong guidelines, and very strong buy-in from the top. The reason why I bring this up is because your work has been known for being you focus very much on accessibility, inclusive design, user-centric design. But then at the same time, if you have all the different layers of politics and all these different layers of business decisions, which in some situations might be more important even than the user research part, how do you even navigate that space? Do you find this or is it maybe the case that now in 2023 or ‘22 still when we’re recording this, that UX is kind of a part of what we do, that it’s understood by stakeholders?

Stéphanie: I think it’s that bad. The way we do it is we navigate around the mess. Basically. We try to stay away. And I am lucky, I work with amazing people who actually shield the team from all the political stuff. So I have people working with us who try to deal with that so that we on the team can do our daily job. And also I think I’m lucky because my manager understands, I’m my manager. The person I’m referring to understands what is UX design and why it’s useful. So they will fight basically for me to have some time to talk to the users. But I’m super lucky in the place where I work, I think we are the only project that’s actually able to have a very user centered approach. And in a lot of area in enterprise UX not everyone is that lucky.

Stéphanie: In a lot of places you have analysts will ask to the user what do they want, and then the users are expected to provide a solution and then the person will just write a technical ticket saying the user wants an export to Excel. Well, if you go there and you’re like, you talk to the user and yeah, but today you don’t have an export to Excel button, so what do you do? And the user shows you the table, they will copy paste the whole table, paste it in Excel, and then you’re like, okay, so it’s in Excel, what do you do now? And then the person goes into one of the column that is the status of something. So it’s either active or inactive, and she just removes all the inactive from the table and she’s like, so we have an analyst that is writing a story saying the user needs an export to Excel button, but the user doesn’t need an export to Excel button in this very specific situation. She needs to remove all the inactive stuff from the screen.

Stéphanie: And yet the export to Excel is the solution she came up with because this is what she does today. But we could also maybe have filters in the browser directly on that table, modern tables and things. So the user need here is not to export to Excel, is to clean up some stuff on the screen and then you come here and you’re like, yeah, but actually no, we are not going to do the export. We will do the export to Excel for other reasons because it’s needed. But for this specific user need, it’s not an export to Excel that we will provide a solution is a filter on the table.

Stéphanie: And unfortunately in a lot of places you have this kind of old school analysis where they will go to people, ask them what they want and then IT will implement it and hopefully find a place somewhere in the screen in a corner to put that button or that feature. So yeah, it’s really, really complicated. But I think at the same time, a lot of people like me are starting to have this kind of change and pushing things forward, but then you don’t make friends all the time, then the old school people are not super happy about you coming and saying, wait a minute, that’s a weird requirement. Can we talk about that and really try to understand what’s going on here?

Vitaly: Yeah.

Stéphanie: Yeah, definitely.

Vitaly: For me, it’s also just really this interesting part because I feel like in a way everything is a little bit of a fight. Sometimes it’s a bigger fight, sometimes it’s a smaller fight. But one thing is even those little things like discovery, I can imagine that it might take, I don’t know, literally months to just discover what are the user needs, how do we make it work? And then apply the good old UX process to it. Maybe you could describe your UX process in general for those kind of projects. Is it just regular way how we do UX or do you have to adjust, do something else? Maybe some methodologies work better than the others? What has your experience been so far?

Stéphanie: So for me, it’s actually faster I think because here I work with my users are the people who work for the bank I work for. We don’t work in the same department, but for recruiting user for tests and things like that, it’s actually easier. I can have a list of the people who use the tool. So in this specific case for me, discovery really, it actually goes a little bit faster because we lose less time in the recruitment. Also, when you go to the people and you say, we are going to talk about the tool that you use in order to improve it. Most of the time people are super happy to talk to you, even if they have a lot of things to do, they’re happy to be invested, that you take time to talk to them to get invested in the project. And it’s a tool they use on a daily basis.

Stéphanie: So I think in my specific case, but here you have to understand the context is I work in the IT department internally, and we provide tools for the users. So I’m not working for a SaaS company that provides B2B employee tools that they resell. So here it’s very specific context and for me it’s actually easier in this case. But for the process, what we have is, so we are redesigning a tool. So we have some basic data, which is server logs that say, okay, how many people visited this page? But then that’s kind of the baseline to say if we migrate some pages, we should migrate first the one that were visited the most. And we have kind of two streams, we have the pages visited the most, and also we have things around user tasks.

Stéphanie: So the user, they need to do some things in the whole process of loan at the bank. So to give you some context, the bank is lending money is just that it’s a European investment bank. So they’re lending money to other countries, to other banks. So it’s not a loan for your car, but it’s kind of has the same principle. You need to build a project, you need to explain what you are going to do with the money, how it’s going to be used and stuff like that. So there’s a lot of different steps and there’s a lot of tasks and activities around that. So a lot of the things we do is we start with the user tasks. So sometimes people ask me about personnel and I’m like, yeah, if I do personnel, if I have 300 of those, and for me, it doesn’t matter if the person is an assistant, a lawyer, an engineer, or we don’t discriminate based on personnel, we discriminate and we do the user research on specific tasks and then we’d check what type of user needs to do this task at which step of the process.

Stéphanie: And in the discovery phase, we will involve the different users from different department who will have to perform this task. We do a lot of interviews. So usually we have kind of interview script where, so I prepare my research plan with the objective of the research, then I write my questions to kind of understand what people are doing. Often it’s kind of open interview where you will ask a few question and then you will connect topics that will go around. Sometimes we go way beyond the research that we’re currently doing, but you’re like, yeah, we’re going to write this down because eventually we will tackle the other topic that the person is currently talking about. So I’m just going to write it down and then take a note that whenever we tackle that specific topic, oh, that’s a user, I can also talk to you to about that.

Stéphanie: So we do a lot of interviews. We do some kind of light shadowing where we ask people to show us to share their screen where we’re working on a specific feature or page. We would be like, okay, then show us where do you go? How does it works? We do a lot of, it’s not really observational. Yeah, it’s kind of observational studies, but with screen sharing. So we are not observing them work as in they do the daily basis, we’re behind them, but we ask them to show how do they perform a task or an activity so that we can get a better understanding of that. And I’m also working a lot with business analysts to understand the business processes because this is super complicated and I can’t know it all by heart to start with. So yeah, mostly discovery interviews. Then we will do some prototype, what needs a big feature and some usability testing on those prototypes.

Stéphanie: What we do is if it’s not such a big feature, we would sometimes just do a design, implement it, and then ask feedback on the implemented version. If it’s something we are pretty confident about and we know we may not have too many user issues or too many question about that, then we will implement it and ask questions or do some light testing once it’s implemented.

Stéphanie: Add then what we did is we onboarding new users and we gave them the user diary, which is an Excel sheet because I work for a bank. So the idea was they use the new interface for a month to see if anything is missing, if there’s some things they don’t understand. And for a month they have this diary where they can log every time there’s something that prevents them from doing their job, whether it’s a bag, a content missing, a feature or something, they put it in the diary log and then we check those diary. We usually come back to them with specific question about certain area. And then we keep on improving the product. So we are not just doing kind of discovery before launching a feature. We also do a lot of back and forth once something is launched and then, yeah [inaudible 00:21:05].

Vitaly: That sounds fantastic.

Stéphanie: Yeah, we support people. So we don’t do the training unless someone asks us to. But every department basically has some support people who are helping the user with different tools, including our tools. So what I usually do is I attend those smaller training sessions because it’s quite interesting also to see how people react the first time they see the interface, what are their questions, stuff like that. So we collaborate a lot. It takes a tremendous amount of time because then it’s one hour meetings where you just sit and listen and watch what the people are doing. So in terms of time, it takes a lot of time, but it also helps gather interesting data.

Vitaly: Do you also use of a speak aloud protocol when people are going through tasks or you just observe mostly how people deal with, I don’t know, with an interface kind of competing the tasks?

Stéphanie: No, we ask them to speak aloud, so we explain what speak aloud means. Because if you’re not UX, you might not mean.

Vitaly: Yes.

Stéphanie: So we try to make people feel comfortable. So some people are amazing at that. They will just tell you what everything that is going on in their brain where they click, what’s weird, and some people even after you told them, please feel free to explain to us what you see on the screen, what’s happening in your mind, why do you want to click somewhere? All of that. They will still just click and say nothing. So we trying to nudge them like, oh yeah, then when they stopped you just say something like, “Oh, you stopped. What is happening? Can you explain us why?” So we try to nudge them without kind of helping them, but yeah, it’s not academic research.

Vitaly: Yeah, yeah, I understand. But do you feel, Stephanie, at this point, after all these interviews, that you can actually read people’s minds when they start clicking around or tap on buttons and so on? Can you just predict what people are doing or do you feel like it’s always almost a miracle? Surprises are always in there.

Stéphanie: Depends on the people. Some stuff you can kind of predict, especially when we test some of the older things that were developed years ago, we kind of anticipate the issues, but no, sometimes on the new things, we have interesting results and you’re like, yeah, actually that makes sense. We should have thought about this. That’s a really good idea. We will do that. We had a column with the name of the person, and we have a place where you have the team member for a specific project. And in the team place, what I did, I put mail to on everyone’s name. So you click on it auto fills an email with the name of the project nicely, the introduction. And people are super happy about that because then they don’t need to copy paste the email of the person anymore. They do all of that.

Stéphanie: And then I have another page where I have the name of the person, I didn’t even think about putting the link there, and the user was like, “Yeah, but we have the link on the teams here. We have also name. Why is it not there?” Ah, actually, yeah.

Vitaly: That makes sense.

Stéphanie: That makes a lot sense. So it’s easy to develop. So yeah, quick win. Definitely. Yeah.

Vitaly: Yeah. Excellent. Well, one thing that surprised me is that you wrote this entire book about customer journey maps and you published customer journey maps, but you did not mention customer journey map as a part of your workflow. Does it not quite fit, or is it just something that you do for other projects?

Stéphanie: Because customer journey map for me is that research method is a tool that you build based on the research. So basically some of the interviews, we worked on a project that was people have to validate tasks, and we actually build a customer journey map for that. But basically we did some interviews and the customer journey map was kind of an artifact kind of result of the user interview. So no, I use customer journey maps a lot, but it’s as if I’m say I and I didn’t learn to mention that I do word frames. To me it’s the kind of same thing.

Stéphanie: It’s not building a customer journey map to build a customer journey map. You are basically doing some research and sometimes you present it as a customer journey map, sometimes as a report, sometimes as an empathy map. But yeah, definitely we have this amazing customer journey where one of the trigger is human notification. And it always makes me laugh so much, which is they have a lot of email and all of the stuff for notification, but kind of the biggest notifications at some point, an assistant picking up the phone and saying, “Hey look, you need to validate this before six tonight. Could you please do it?” So we have this whole journey with human notification in the middle, which is quite funny.

Vitaly: Well, that’s the enterprise world for you, I guess in some way or the other. I’m also wondering now I can only imagine that it takes quite a bit of time to even work in this space, but then you always find time to, I don’t know, read a lot apparently, because every time I jump into LinkedIn or on a blog, it’s just an incredible wealth of resources all around things from CSS to UX to freebies, goodies, whatever, everything. So how does that work? Where do you find all of the stuff? Do you just spend time, I don’t know, during your pizza experiences by reading articles all around design front and then UX.

Stéphanie: Okay, so the big secret is most of the articles, I don’t read them, I listen to them.

Vitaly: No, come on Stephanie. You can’t say that.

Stéphanie: No. I listen to them.

Vitaly: Oh, so you listen to them.

Stéphanie: Yeah, I listen to them.

Vitaly: Please share details.

Stéphanie: Which means in Firefox you have, I think it’s called Reading Mode, but you can ask Firefox to read the article to you. So usually a lot of the super long in-depth articles, I don’t have the patience to read them on a screen, so I will just put the headset on my ears and then I will listen to the article while cooking, cleaning the dishes, doing [inaudible 00:27:34] for the moving of my flats and stuff like that. So yeah, that’s the secret. It’s like I’m multitasking and often I’m listening to the articles while doing manual labor that doesn’t need my brain.

Vitaly: Right. But I assume that compiling the list of links and writing on LinkedIn is done manually.

Stéphanie: Yeah, yeah. I have actually where it is basically, I can schedule things on LinkedIn and Twitter at the same time, so it makes it a little bit easier. It just allows me to post, so I enter it once. Sometimes I need to check for the handles because the tool is able to get the Twitter handles, but not the LinkedIn handles. So if I post something on LinkedIn, I need to tag someone, I need to go back to the post and edit it, which is a little bit annoying. And also sometimes I will not read anything for a whole day and just read, I don’t know, 10 articles during the weekend. And I don’t want to annoy people with an article during the weekend, so will just schedule the post so that it’s not kind of overwhelming and posting everything at the same time. So yeah, organization and having an AI.

Vitaly: So I think that-

Stéphanie: A screen reader read the articles to me.

Vitaly: I think that enterprise world taught you how to be very well organized, but I’m sure that you’ve been organized even before that as well. I can almost hear some people in the back asking, “But I’m interested in getting into enterprise UX.” So maybe kind of jumping back on quickly to the topic, I’m wondering are there particular roles, skills that you think are absolutely important to be able to comfortably navigate that enterprise UX space? Or is it just the regular UX work, just more challenging?

Stéphanie: I think definitely information architecture and the ability to make sense of a lot of data and kind of organizational skills as on information in UI level, because you will get a lot of information thrown at you in enterprise. The business is so complicated that you need to make sense of all the mess. And there’s an amazing book that I think it’s called Making of Sense of the Mess, Abby Covert. She wrote a book on information architecture and she wrote a second book on diagrams, which I really like as well. And so yeah, I would say if you want to work in enterprise UX, it’s definitely being able to not be scared of the complexity because you will get a lot of complexity to deal with on a daily basis. And then, yeah, information architecture is one of the biggest skills at some point to make sure that you arrange the content in a way that makes sense to the user.

Stéphanie: You cannot comprehend all the complexity of the business behind that. Yes, but it’s a bit tricky. Also, I think you need to understand that you might need to let go of all the UI principle that are taught in mainstream articles, like make the font bigger and put some more white space. And no. I have places who wants a small font, they want as much data as possible on the screen, they don’t want to scroll. So if you could condense everything on one single screen. So all these fancy article that say, yeah, big font size are trendy there, it’s like, yeah, sure on blogs and marketing websites, but in my world, nah.

Vitaly: Yeah. So I can only agree with you on that because I think in many ways what my job has been is really trying to keep as I’m really literally also show as much information as possible in given place. And then of course you have a table with filters, with sorting, with multi sorting, with all those things, and they all have to be visible and then you need to add some batch actions on top of that and export features and whatnot. And then it has to kind of in some way or the other, work on mobile as well.

Stéphanie: So this is a very different world for sure. So I think it would definitely be a good idea to see, just to be able to explore or see more case studies and work done in that world as well. But I heard that enterprise UX actually is just one part of your story because you are also interested in other things like for example, illustrations and graphic design. And on your beautiful blog, you also of course have your beautiful illustrations, and every now and again one can see your illustrations, but do you even have time for it now that you are so, I don’t know, so deep dive into this messy world of tables, filters, forms, and all of that. Do you have time for your beautiful graphic design illustration work?

Stéphanie: Yeah, usually in the evenings or weekends when I have a topic that I’m interested in too. This is also why I could not be a professional illustrator because I don’t know, how do you illustrate something someone else asks you to do? So all the illustration I’m doing is just like, yeah, I have this really fun idea and I’m going to draw it, and that’s basically it. So I would not be able to have someone tell me, oh, could you do an illustration on that on that, so I admire illustrator who are able to do that work for other people and stuff. For me it’s kind of just a hobby and just having fun illustrating kind of funny things.

Stéphanie: And also I blame Instagram, they have this Domestica advertisements. So Domestica is a website where you can learn a lot of art, craft and stuff. Really like this illustration, I think the pottery, how to build furniture out of wood. I’ve done some courses on that. So it’s really all the creativity stuff and sometimes they’re pushing me advertisement on my Instagram’s like, “Hey, do you want to do a new class on [inaudible 00:33:37] illustration? I was like, “Damn it.”

Vitaly: Right?

Stéphanie: Another class on [inaudible 00:33:44] illustration just for fun.

Vitaly: But it’s unlikely that you’re going to give up your wonderful world of enterprise UX for that. Will you?

Stéphanie: No, no. Yeah, I prefer, I think it’s kind of tough to be in enterprise UX because there’s a lot of politics and so it’s very, very demanding. But artist world, illustration world, then this sounds even worse with everyone thinking they can just do whatever they want. Copyright issue, content theft AI as you know who are fed by styles of a specific artist and you can create-

Vitaly: Well who knows Stephanie, maybe at some point we just waiting for a startup to be building an enterprise AI constructor bot something using mid journey and whatnot.

Stéphanie: I don’t see that. But that’s the same as a package. And everywhere where they bought a package, I saw it fail. Either it didn’t work or you end up with some users super frustrated. In one company they bought a package and they could not have it involved anymore because the company went bankrupt and they basically repurposed some of the labels. So it’s like, okay, this label is something, but it does something completely else. And everyone knows that if you want to do that, you need to click on this label that has nothing to do. But they can’t change the label.

Vitaly: Oh well I think it sad.

Stéphanie: Yeah, I’m like, yeah, I’m curious to see what AI and stuff can do for enterprise UX. But honestly I don’t know.

Vitaly: A little bit skeptical. I can tell from your voice and from the way you answer that question, well, but I’m wondering if your students challenge you because of course you also teach for University in Strasbourg and also online and you also provide mentorship. And not only do I wonder just how do you find time for it all, but I understand that one, I mean for me it’s kind of the same story. I always kind of make time for it. It’s not about finding time, it’s kind of making time for it. But I do want to ask at this point, what is for you, the most rewarding part about this? I can tell that of course, you’re very passionate about disability and design interface design and the world of enterprise UX one can tell of course as well, I think it might be a little bit difficult to convey to students all the difficult part about enterprise UX and how to apply UX work in enterprise UX setting. Or are you teaching something that’s maybe a little bit more just general UXy? And again, just the experience. What would be the most rewarding part for you of taking time to do this?

Stéphanie: So I am teaching mobile usability and UX design applied to mobile and responsive design. So it’s not specifically enterprise UX, but the cool thing is I’m teaching a framework which helps people build products and services with reusable components. And I think that’s the interesting part because then the students are super happy that I’m providing a framework to help them deal with the complexity. And sometime they will be like, yeah, I’m not sure where the teacher is going with this framework. But then after they started working, they’re like, oh, I remembered your course. And then I used that framework and it totally helped me kind of make sense of the mess and stuff. So I have a very small part of my course that is dedicated to information architecture and how to build reusable components for responsive web design. So components that can adapt to different screen sizes or that you can reuse in a big area in a smaller area.

Stéphanie: So I’m not going in all the media query and container query detail, that would be the technical part. But basically I’m preparing designers to be ready for that. And I had a lot of feedback that was like, “Oh, I went back to work on Monday and I reuse what you taught us.” And I think this is what drives me, the best feedback you can give someone who is teaching a workshop is on Monday morning, I was able to apply something I learned from you last week, which is amazing because then you really made a difference in that person’s work. So I think it’s the same for students. I’m like, I’m pretty sure that they are not super convinced that everything I’m teaching them today is going to be useful, but at some point later in their career, they will remember, oh yeah, we didn’t know how to decide if we needed to build a mobile or native app.

Stéphanie: But then we remembered was Stephanie said about starting with the user need and checking what makes sense based on the user needs, so user need first, and then decide on the technology instead of deciding technology and try to feed the user need into that technology, which makes very little sense. So it’s often about, but it’s the same for some of my classes. While you are in the class, you’re like, yeah, okay, it’s interesting, but I’m not sure if I’m ever going to reuse that. And then a few years later, you’re working. I like, huh, yeah, actually that was very useful.

Vitaly: That is indeed I’m sure, a very rewarding experience. I think it’s always just getting some sort of a feedback from people who, I don’t know, read something that you posted or found something useful. And all this is in many ways kind of the fuel of motivation to keep going and explore and keep exploring and keep growing. But also, actually one thing that I ask myself a lot based on that, every time it comes to a point where I realize, okay, well these are some bits of knowledge that I’ve gathered and I presented maybe, and then somebody learned from that, I always try to look back and see when did I learn that actually? Or how did I learn that? And how did it evolve over time maybe. So the question that I’m thinking of at this point is when you look back at your career, what do you wish you would’ve told yourself 10, 15 years ago? Or what do you wish you, I don’t know, how would you wish you would have structured your career? Or do you feel comfortable where you are? Do you feel like you would’ve done something a little bit differently, looking back?

Stéphanie: I would’ve loved to have more psychology. I have this whole thing on, we created some [inaudible 00:40:25] on cognitive biases of years ago with a trend and it’s kind of blown up. I have people in different institutions and in some company using it to help their colleagues understand cognitive biases. And definitely I think I would’ve liked to have a little bit more background in psychology, cognitive psychology, behavioral psychology, also as a UX designer. But at the same time, I think when I was a student, this kind of UX career path didn’t really exist per se. So in France you had something called ergonomic, which is an issue with ergonomics. That’s my problem. Ergonomics. Ergonomics is chair and posture and how do you make sure physical, but ergonomy in French is both, it’s either the chair, but it can also be the usability part.

Stéphanie: So it’s a tricky word to translate. So there’s some master degree that in psychology that you prepare you to become an ergonomist in the English version of the world, which is you go to the people, you observe how they work and then you try to help them with postures or moving around things, but also adapting their workspace and adapting the processes and stuff like that. And it’s kind of linked to mastering, is it mastering? No, it’s a license. So it’s a bachelor in psychology in France, but this is not your design again, it’s something else. So I wish I had kind of more of a background in that. So now I’m trying to compensate with some online learning, some books and a lot of that. But yeah, definitely I would say if you want to become a UX designer and really if you are interested into that, having a little bit of background in how does the human brain work when it comes to memory, how do we learn, how do we perceive information, all of that can be very, very helpful.

Vitaly: I remember the last one that would be, that’s always something I ask because who knows who is going to listen to this podcast at some point, well, this year or in a few years. Is there a particular dream project that you ever wished or always wished you would be working on? I mean, you are working on some pretty complex environments and projects already, but if you had to pick your battle, what would be one of the really interesting products, companies, challenges, dream projects that you ever wished you could work on?

Stéphanie: I don’t know honestly, but I think something around maybe service design or more having stuff built in to not only the UI but also the whole service around it. So maybe connected houses or kind of helping in different area, maybe working on some tools in factory for instance. I would love to do that, go there, observe how do people work, and then optimize the tool to help them in their daily job. So kind of a mix between a little bit of interface, but also a lot of work around service design, process design, things like that. I think this would be cool. I’ve seen some that Airbus, a plane company was looking for an intern and was like, oh gosh, I would’ve loved to be a York’s intern for Airbus when I started. Because I think it’s working on the cockpits and the UI interface of a plane. That must be something quite challenging and quite fun.

Vitaly: You do a good challenge, one can tell. Wait and see, wait and see Stephanie, wait and see, who knows. Well, so we’ve been learning today what enterprise UX is, but maybe as a final word from you Stephanie, what have you been learning recently? You’ve been publishing, linking to all the articles and mentioning all the tools. What were some of the really interesting things that you learned recently?

Stéphanie: I think I shared it last week. Gary Reid had a super interesting take on [inaudible 00:44:44] 3.0 and the need or not need of interfaces. A lot of interesting thought on how Web3 is not accessible and not open at all, even if people are trying to tell you that it’s open and easy. So yeah, I really like that her take mixing what’s coming in the new work and kind of accessibility in the future and how we will include human being in different experiences. That is something that I really like that talk that she gave because it’s really cool to try to imagine and foresee the future in a not bullshit way, because it’s the end of the year. We will get the trends for next year and it’ll be all bullshit. But her talk is actually, it sound did grounded on reality. So that was really, really cool.

Vitaly: Yeah, that’s interesting. I’m very excited actually about this plethora of articles around all the cool and important and less important digital trends in 2023. Always look at them and then think, huh, let’s see how well we or better we have become in predicting the future. It didn’t look very good over the last decade or so at all. Well if you, dear listener, would like to hear more from Stephanie, you can find her on Twitter where she’s @WalterStephanie and on LinkedIn where she’s Stephanie Walter Pro and on her website StephanieWalter.design, Stephanie will also be running a workshop on designing better products for Smashing Workshops. So please drop in if you have time. I totally forgot to ask about that, Stephanie, but is it true that you are running that workshop?

Stéphanie: Yay. I hope so. It should be a lot of fun. It should be about dealing with complexity of product, giving people, again, a framework to help them. And I hope they will be happy and find something that will help them deal with complexity on the work on the Monday morning also-

Vitaly: Oh, you do like complexity?

Stéphanie: Yeah.

Vitaly: Excellent, excellent. So that sounds very, very good. So please do join us on November 28th and December 12th where we’re going to dive in into designing by the products with Stephanie. I’m very excited about that. Well, thanks for joining us today, Stephanie. Do you have any parting words or wisdom that you would like to send into the universe by people who actually manage to listen to the very last sentence of this podcast?

Stéphanie: No, I don’t know. I’m really bad at this.

Vitaly: We all are.

Stéphanie: Stay safe maybe. And yeah, I think stay safe is still something we need to make sure, even if the pandemic seems to be a little bit over. Yeah, stay safe.

A Guide To Keyboard Accessibility: HTML And CSS

 This article is the first of two parts about a guide to making websites accessible to keyboard users. Here Cristian Diaz covers a good set of practices and recommendations on how to use HTML and CSS to create a great experience for keyboard users.

Keyboard accessibility is an important part of the user experience. There are multiple criteria in Web Content Accessibility Guidelines (WCAG) about this topic. Still, it’s somehow overlooked, affecting the experience of many users, mainly people with motor disabilities — any condition that limits movement or coordination.

Certain conditions like having a broken arm, the loss or damage of a limb, muscular dystrophy, arthritis, and some others can make it impossible for a person to use a mouse to navigate a site. So, making a site navigable via keyboard is a very important part of ensuring the accessibility and usability of our websites.

The importance of making a site accessible for users with motor disabilities becomes even more evident when you learn that they have access to more assistive technology options. Keyboards are not even the main focus of motor disability assistance! There are tools like switches that you use with your hand (or even with your head) to work with any device, which helps a lot for people with more severe motor disabilities. You can see how those technologies work in this demonstration made by Rob Dodson or in this video of Christopher Hills.

In this article, I’ll cover how to use HTML and CSS to create an accessible experience for keyboard users while mentioning what WCAG criteria we should keep into consideration.

HTML #

One of the basics of creating a website accessible site for keyboard users is knowing what elements should be navigable via keyboard. For this, a good HTML semantic is crucial because it’ll indicate the kind of elements we want to focus on with keyboard navigation.

The Basics #

When a user presses the Tab key, it’ll let them select the next focusable element in the HTML, and when they press the keys Shift + Tab, it’ll take them to the last focusable element. With that said, what elements need to be focusable? Anything that requires user interaction. Between them, you can find the elements button, a, input, summary, textarea, select, and the controls of elements audio, and video (when you add the attribute controls to them). Additionally, certain attributes can make an element keyboard navigable, such as contenteditable or tabindex. In the case of Firefox, any area with a scroll will also be keyboard focusable.

Additionally to that, you can:

• Activate the button, select, summary, and a elements using the Enter Key. Keep in mind that except for the a element, you can activate them with the Space Key as well.
• Use the arrow keys to navigate between different input with the type radio if they share the same name attribute.
• Check those inputs using the Space key (keep in mind that when you navigate with the arrow keys radio inputs, it’ll be checked once the keyboard is focused, but that doesn’t happen with checkbox inputs).
• Use the up and down keys to navigate between the different options of a select element.
• Close the select element displayed list and multiple input popups.
• Use the arrow keys to scroll vertically or horizontally a document.

There are probably more interactions, some of which depend on differences between operating systems and browsers, but that covers mostly what you can do with the keyboard.

Does that mean those elements are automatically keyboard-accessible by default? A good HTML structure is very helpful, and it makes content mostly accessible by default, but you still need to cover some issues.

For example, certain input types like date, datetime-local, week, time, and month have popups that can work differently between browsers. Chrome, for example, allows you to open the date picker popup by pressing the Enter or Space key in a designated button in the input. However, with Firefox, you need to press Enter (or Space) in either the day, month, or year fields to open the popup and modify each field from there.

This lack of consistency can be a bit off-putting, and maybe it’s just a matter of personal preference. Still, I feel that the Firefox experience is not very intuitive, which leads to thinking that, arguably, one of those experiences is more keyboard-accessible than the other. So if you want to create a good, accessible, and consistent keyboard experience between browsers, you’d need more than HTML for that. If you’re going to try it yourself, check this compilation of input types by MDN and navigate them by yourself.

Additionally to the previous point, certain components require elements to be keyboard focusable without being natively selectable. In other cases, we need to manage keyboard focus manually, and our markup needs to help us with that. For both cases, we’ll need to use an HTML attribute that will help us with this task.

tabindex Attribute #

This attribute will greatly help us bring keyboard accessibility to more complex component patterns. This attribute receives an integer, and properly using it will help us make a DOM element keyboard focusable. With tabindex, we can find three different cases:

tabindex="0" #

It causes the element to be keyboard focusable. You usually don’t want to add keyboard focus to an element unless it is not interactive, but some scenarios will require it.

One of them is when you have a component with a scroll beside the body element. Otherwise, keyboard users won’t be able to see the full extent of the content. Some components that could have this trouble are scroll-based carrousels, tables, and code snippets. Just to give an example, any code snippet created with the help of prism.js has the attribute tabindex="0". Open prism.js’ site and navigate it using the Tab key. You’ll be able to focus the snippets and control the vertical and horizontal scroll using the arrow keys.

(Large preview)

Some people who start with web accessibility think it is a good idea to add the attribute tabindex="0" to every element because they think it’ll help screen reader users navigate easily through a site. This is a terrible practice because of two reasons:

1. Screen reader users have multiple ways to navigate a site. They can jump between headers, landmarks, or form elements, and they don’t need that extra help to create an accessible site as long as the markup is appropriate.
2. It can make keyboard navigation difficult because a user will have to press the Tab key many times to arrive at the desired content, and for certain motor disabilities, having too many focusable elements can create a physically painful experience.

So, to summarize: it’s a useful technique for some components, but most of the time, you’ll be alright if you don’t use it, and certainly, you must not use it in every single element of your site.

Negative tabindex #

Before we start this section, we need to keep in mind two concepts: a DOM element is at the same time focusable (that means, you can programmatically focus on it with JavaScript) and tabbable (that means, being able to be selected with the Tab Key).

With that in mind, here is where negative tabindex comes into play because it’ll make an element unable to be tabbed (but you can still focus on it with JavaScript). This is important for specific components because, in some cases, we’ll need to make a normally tabbable element unable to be tabbed, or we’ll need an element to be focusable but not tabbable.

One example of that is tabs. A recommended pattern for this component is ensuring that when you press the Tab key when you’re located in the active tab, it goes to the active tabpanel instead of bringing the focus to the next tab. We can achieve that by adding a negative tabindex to all non-active tabs like this:

<ul role="tablist">
  <li role="presentation">
    <button role="tab" href="#panel1" id="tab1" aria-selected="true">Tab one</button>
  </li>
  <li role="presentation">
    <button role="tab" href="#panel2" id="tab2" tabindex="-1">Tab two</button>
  </li>
  <li role="presentation">
    <button role="tab" href="#panel3" id="tab3" tabindex="-1">Tab three</button>
  </li>
  <li role="presentation">
    <button role="tab" href="#panel4" id="tab4" tabindex="-1">Tab four</button>
  </li>
</ul>

We’ll see more examples later about how a negative tabindex will help us to have more control over focus state management in different components, but keep in mind a negative tabindex will be important in those cases.

Finally, you can put any negative integer in the tabindex property, and it’ll work the same. tabindex="-1" and tabindex="-1000" will make no difference, but my mere convention is that we tend to use -1 when we use this attribute.

Positive tabindex #

A positive tabindex will make the element keyboard focusable, but the order will be defined according to the used integer. That means that first, the keyboard will navigate all elements with the attribute tabindex="1", then the ones with tabindex="2", and after all elements with a positive tabindex have been navigated, it’ll take into account all interactive elements by default and those with the attribute tabindex="0". This is known as the tabindex-ordered focus navigation scope.

Now, this is a pattern that you shouldn’t use. You’ll be better if you put the required focusable elements in your site in the order you need. Otherwise, you could create a very confusing experience for keyboard users, which would make a failure of the WCAG criterion 2.4.3: Focus order.

“If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.”

— Success Criterion 2.4.3: Focus order

It might be useful if you want keyboard users to focus on widgets before they reach the page content, but that’d be a bit confusing for assistive technology users (like screen readers). So again, you’d be better by creating a logical order in the DOM.

inert Attribute #

I have to quickly note an incoming attribute that will help us a lot with keyboard accessibility called inert. This attribute will make the content inaccessible by assistive technologies.

Now you might be asking yourself how this can be useful because if something removes keyboard accessibility, but in some cases, that’s a good thing! One component that will benefit from it is modals. Adding this attribute to all elements in the site except this modal will make it easy to create a focus trap. So you’ll ensure the user can’t accidentally navigate to other parts of the site using the Tab key unless they close that modal. Right now, creating a keyboard trap requires quite some thinking with JavaScript (I’ll explain how in the second part of this guide). So, having a way to make it easier with this attribute will be handy.

Sounds pretty cool, right? Well, unfortunately, this attribute is not recommended to be used yet. If you check the caniuse.com entry about this attribute, you’ll notice it’s very recent; Opera doesn’t have support for it yet. The most recent implementation of it was version 105 of Firefox, and at the moment of writing this article, it’s a beta version! So, it’s still very early to do it. There is a polyfill for inert attribute, but right now, it’s a bit performance costly. So, I seriously suggest not using it now for production. But once we have adequate support for this attribute, some component patterns will be easier to create.

More after jump! Continue reading below ↓

Meet Smashing Online Workshops on front-end & UX, with practical takeaways, live sessions, video recordings and a friendly Q&A. On design systems, UX, web performance and CSS/JS. With Brad Frost, Stephanie Troeth and so many others.

Jump to the workshops ↬

CSS #

CSS is an essential tool for keyboard accessibility because it allows us to create a level of customization of the experience, which is important for compliance with WCAG 2.2 criteria. Additionally, CSS has multiple selectors with different uses that will help to create a good keyboard experience, but be careful because a bad use of certain properties can be counterproductive. Let’s start diving into the use of this language to create an accessible experience for keyboard users.

Focus Indicator #

When you use a mouse, you can see which element you can interact with it thanks to the cursor, and you wouldn’t remove the cursor from your user, right? That’d make them unable to know what element they want to use!

We have a similar concept for keyboard navigation, and it’s called a focus indicator, which by default is an outline that surrounds a keyboard-focusable element when it’s selected by it. Being sure all your keyboard-focusable elements have a focus indicator is essential to making a website keyboard accessible, according to WCAG criteria:

“Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.”

— Success Criterion 2.4.7: Focus Visible

This style is different depending on the browser you’re using. You can see how it looks in the various browsers in those pictures by default and when you use the CSS property color-scheme set to dark just to check out how the default styles would behave in dark mode.

Chrome’s focus indicator. (Large preview)

Firefox’s focus indicator. (Large preview)

Safari’s focus indicator. (Large preview)

As you can notice, Chromium-based browsers like Chrome or Edge have a black and white outline, which works in light and dark mode. Firefox opted for a blue outline which is noticeable in both modes. And Safari (and Webkit-based browsers because right now, all iOS browsers use Webkit as their browser engine) looks almost the same as Firefox but with an even subtler outline for a dark color scheme.

WCAG Criterion 2.4.11 #

Now, default focus indicators are visible, but are they enough? The answer is “no”. While it can work in some cases, people with visual impairments will have problems noticing it, so WCAG created the Success Criterion 2.4.11 — Focus appearance to make an accessible focus indicator. Right now, this criterion is part of WCAG 2.2, which is a Candidate Recommendation. So it’s quite unlikely it will change before the final release, but keep in mind that it’s still subject to changes.

When the keyboard focus indicator is visible, one or both of the following is true:

1. The focus indicator:
   • encloses the visual presentation of the user interface component, and
   • has a contrast ratio of at least 3:1 between the same pixels in the focused and unfocused states, and
   • has a contrast ratio of at least 3:1 against adjacent colors.
2. An area of the focus indicator meets all the following:
   • is at least as large as the area of a 1 CSS pixel thick perimeter of the unfocused component, or is at least as large as a 4 CSS pixel thick line along the shortest side of the minimum bounding box of the unfocused component, and
   • has a contrast ratio of at least 3:1 between the same pixels in the focused and unfocused states, and
   • has a contrast ratio of at least 3:1 against adjacent non-focus-indicator colors, or is no thinner than 2 CSS pixels.

Where a user interface component has active sub-components, if a sub-component receives a focus indicator, these requirements may be applied to the sub-component instead.

— Success Criterion 2.4.11 Focus Appearance

There is something important to consider here, and that’s the area of the focus indicator. This area needs to meet the contrast requirements of this criterion. To illustrate that, I’ll use an example Sara Soueidan made for her article “A guide to designing accessible, WCAG-compliant focus indicators.”

Credit to Sara Soueidan. (Large preview)

This example uses an outline, but remember that you can use other properties to determine the focus state, like background-color or some creative ways of using box-shadow as long as it’s compliant with the requirements. However, don’t use the property outline: none to eliminate the element’s outline.

That’s important for Windows High Contrast Mode because when it’s active, your website colors will be replaced with ones chosen by the user. So depending on properties like background-color will have no effect there. Instead, use the CSS declaration outline-color: transparent with the appropriate thickness to comply with WCAG criteria. You can see examples of how it works in my article about Windows High Contrast Mode.

The Optimal Outline Size #

An easy way to create a compliant focus indicator is using this method Stephanie Eckles suggested in her talk Modern CSS Upgrades To Improve Accessibility. First, we set custom properties in the interactive elements. Remember you can add more elements to the rule depending on the complexity of your project:

/* Add more selectors inside the :is rule if needed */

:is(a, button, input, textarea, summary) {
    --outline-size: max(2px, 0.08em);
    --outline-style: solid;
    --outline-color: currentColor;
}

And then, we use those custom properties to add a global focus rule:

:is(a, button, input, textarea, summary):focus {
    outline:
      var(--outline-size)
      var(--outline-style)
      var(--outline-color);
    outline-offset: var(--outline-offset, var(--outline-size));
}

The use of 0.08em here is to give it a bigger outline size if the font is bigger, helping to scale the element’s contrasting area better with the element’s font size.

Keep in mind that even when WCAG mentions that the focusing area “is at least as large as the area of a 1 CSS pixel thick perimeter of the unfocused component”, it also mentions that it needs to have “a contrast ratio of at least 3:1 against adjacent non-focus-indicator colors, or is no thinner than 2 CSS pixels.” So, a minimum thickness of 2px is necessary to comply with WCAG.

Remember that you might need a thicker line if you use a negative outline-offset because it’ll reduce the perimeter of the outline. Also, using a dashed or dotted outline will reduce the focused area roughly by half, so you’ll need a thicker line to compensate for it.

The outline’s ideal area is related to the perimeter of the element. Sara Soueidan once again did a great job explaining how this formula works in her article about focus indicators. So check it out if you want to understand better the maths behind this matter and how to apply them.

CSS Focus-related Selectors #

With CSS, you normally use the pseudo-class :focus to give style to an element when it’s being focused by a keyboard, and it does its job well. But modern CSS has given us two new pseudo-classes, one that helps us with a certain use case and the other that solves an issue that happens when we use the focus pseudo-class. Those pseudo-classes are :focus-within and :focus-visible. Let’s dive into what they do and how they can help us with keyboard accessibility:

:focus-within #

This pseudo-class will add a style whenever the element is being focused or any of the element’s children is also being focused. Let’s make a quick example to show how it looks:

<form>
  <label for="name">
    Name: 
    <input id="name" type="text">
  </label>
  <label for="email">
    Email:
    <input for="email" type="email">
  </label>
  <button>Submit</button>
</form>

Very quick tangent note: Consider not using label to wrap the input element. While it works in all browsers, it doesn’t work well with Dragon speech recognition software because it won’t be recognized appropriately.

form {
  display: grid;
  gap: 1em;
}

label {
  display: grid;
  gap: 1em;
  padding: 1em;
}

label:focus-within {
  background-color: rebeccapurple;
  color: white
}

(Large preview)

This pseudo-class is interesting to enrich the styles of certain components, as previously shown, but in others, it helps a lot to make content accessible for keyboard users. For example, I created a card for my article about media queries hover, pointer, any-hover, and any-pointer. This card shows the content when the user puts the cursor on it, but it also shows the content when you focus the button inside of it using the :focus-within pseudo-class by using the same rules that are triggered on hover. You can check out the code in the mentioned article as well as in this CodePen:

See the Pen Keyboard accessible animated card [forked] by Cristian Diaz.

focus-visible #

On the other hand, we have quite interesting behavior with focus styles due to how the browser decides when to apply this state to an element. If you use the :focus pseudo-class, most browsers will take clicking the element as focusing it, which creates a “false positive” where the element looks like it’s being focused by a keyboard when it’s not the case.

To solve that minor issue, we now have the pseudo-class :focus-visible that creates a focus state only and just only when the element is being focused with a keyboard. Keep in mind that this behavior will apply to elements like button or a and most input elements like the one with the types checkbox, radio, or submit. But it’ll still apply the focus styles when you click them in elements like select, certain input that receive any kind of text like text, number, or the textarea element.

This doesn’t happen nowadays because modern browsers use :focus-visible as their default focus state. But remember, you likely want to change the browser’s default focus indicator to be compliant with WCAG 2.4.11, so you’ll need :focus-visible to avoid this behavior.

If you check the caniuse.com entry about focus-visible pseudo-class, you’ll notice it’s active in all browsers. But in Safari, it has been active since a relatively recent version (15.4, which was released on March 13th, 2022), which means some users probably haven’t updated their browsers yet. That means we should offer any kind of fallback if the browser doesn’t support this pseudo-class. We can do that using the @supports feature query.

Previously, we created a good global style for focus style, now let’s apply the :focus-visible pseudo-class to this rule:

@supports selector(:focus-visible) {
  *:focus {
      outline: none
  }

  *:focus-visible {
      outline:
        var(--outline-size)
        var(--outline-style)
        var(--outline-color);
      outline-offset: var(--outline-offset, var(--outline-size));
  }
}

Quick note: I know I mentioned using the rule outline: none isn’t a good idea, but as we’re replacing it with :focus-visible, this is an “ok” scenario to use it. Just remember to use outline even if it’s not visible. Outline is your friend!

Layout Considerations #

Modern CSS power to create layouts is great, but there is a set of practices we should try to use with caution because it can make keyboard navigation experience a problem.

display: contents #

This rule is very interesting. It removes the element’s box and makes the element’s children act as if they were direct children of the grandparent’s element without removing the semantics. It makes an element’s child behave as if it were its siblings. This might look a bit confusing, so I’ll explain it with an example. Let’s suppose we have this site’s header’s markup:

<header>
  <a href="#">Go to home</a>
  <nav>
    <ul>
      <li>
        <a href="#">Clothes</a>
      </li>
      <li>
        <a href="#">Accessories</a>
      </li>
      <li>
        <a href="#">Shoes</a>
      </li>
    </ul>
  </nav>
</header>

If we add the rule display: contents to the ul element, we’d be removing the box without removing the semantics, so it’d make the li elements as children of ul’s parent element (in this case, the nav container) like that:

<header>
  <a href="#">Go to home</a>
  <nav>
    <li><a href="#">Clothes</a></li>
    <li>
      <a href="#">Accessories</a>
    </li>
    <li>
      <a href="#">Shoes</a>
    </li>
  </nav>
</header>

And again, that’s without removing the parent element’s semantics. That brings some interesting possibilities for layout creation, as Kevin Powell explains in his video about this property. However, it has a behavior with interactive keyboard elements that should be avoided.

Using it in a keyboard focusable element will make those elements unable to be tabbed. To be fair, it’s very unlikely you find yourself in a situation where you have to use display: contents in a keyboard-focusable element (the only one I could think of if you want to use it to reset the styles of those elements). And this property’s accessibility concerns are for other more common reasons (Safari has a bug that removes the semantics for table and button elements in version 16), but if you somehow find yourself in this situation, avoid it at all costs.

Grid And Flex’s order Property #

Grid and flexbox have changed what we can do with layout creation. They’re amazing tools that help us create layouts as complicated as we want, but remember that they can create accessibility issues.

As Manuel Matuzović mentioned in his talk The Dark Side of the Grid, when we change the order of elements visually either by defining an explicit order in a grid with properties like grid-row and grid-column or using the property order on flexbox or grid, it won’t change the order of how the elements appear in the DOM.

This mismatch between DOM and visual order can create a confusing experience for many users, including keyboard users. If we change the visual order too much, it can create a confusing experience for them because the keyboard navigation might not work logically. As I mentioned in the section about positive tabindex, the WCAG criterion 2.4.3 — Focus order, this keyboard navigation needs to preserve an order that “preserves meaning and operability.”

Let’s check that with an example. Let’s take a look at this markup, and let’s order them using a grid:

<ul role="list">
  <li><button>1</button></li>
  <li><button>2</button></li>
  <li><button>3</button></li>
  <li><button>4</button></li>
  <li><button>5</button></li>
  <li><button>6</button></li>
  <li><button>7</button></li>
  <li><button>8</button></li>
  <li><button>9</button></li>
</ul>

button:focus {
  outline: max(2px, 0.08em) solid currentColor;
  outline-offset: -7px;
}

@supports selector(:focus-visible) {
  button:focus {
    outline: none;
  }

  button:focus-visible {
    outline: max(2px, 0.08em) solid currentColor;
    outline-offset: -7px;
  }
}

(Large preview)

If you use keyboard navigation, you’ll notice the order is pretty straightforward. It reads from left to right and from top to bottom, and the navigation will be the same. Now let’s use grid properties to make some changes:

ul li:where(:nth-child(1), :nth-child(5), :nth-child(7), :nth-child(9)) {
  grid-row: span 2;
  grid-column: span 2
}

ul li:where(:nth-child(1), :nth-child(5)) {
  order: 2;
}

ul li:where(:nth-child(7), :nth-child(8)) {
  order: -1;
}

ul li:nth-child(4) {
  grid-row: 3;
  grid-column: 2 / span 2;
}

ul li:nth-child(3) {
  grid-row: 5 / span 3;
  grid-column: 3;
}

(Large preview)

Now it looks completely disarrayed. Sure, the layout looks funny, but when you start navigating it with the Tab key, it’ll have a very random order. There is some degree of predictability now because I used numbers as the button’s label, but what happens if they have different content? It’d be impossible to predict which would be the next button to be focused on with a keyboard.

This is the kind of scenario that needs to be avoided. It doesn’t mean you can’t explicitly order an element within a grid or use the order property. That means you need to be careful with managing your layouts and be sure the visual and DOM order matches as much as possible.

By the way, if you want to try it by yourself, you can see the demo of this code here and experience this chaotic keyboard navigation by yourself:

See the Pen Focus order demo [forked] by Cristian Diaz.

• 
  A React Data Grid that makes a developer’s life easier? Yes, there is one: the KendoReact Grid
  Get a Data Grid!

Some Component Patterns #

With what we have seen about HTML and CSS, we can create some simple components to help improve the experience for keyboard users.

Accordions #

We can create keyboard-accessible accordions with just HTML thanks to details and summary elements. It has keyboard navigation by default, and screen reader’s support is quite good, be careful with certain interactions between screen readers and browsers, though, as Scott O’Hara points out in his article about details and summary elements, some interactions don’t show important changes when users interact with them. So probably, you could enhance it with JavaScript to support those cases, but this component’s accessibility is pretty great by default, especially for keyboard navigation, which is our main concern in this article!

This is the HTML structure:

<details>
  <summary>
    <h2>Title</h2>
    <span aria-hidden="true"></span>
  </summary>
  <p>
    <!-- Content -->
  </p>
</details>

And this is how it’d look when the components are in their contracted and expanded states:

(Large preview)

(Large preview)

Now let’s start styling this component! By default, this element uses this triangle to indicate if the details element is opened or closed. We can remove that by adding this rule to the summary element.

summary {
  list-style: none;
}

But we’ll still need a visual indicator to show if it’s opened or closed. My solution is to add a second element as a child of summary. The important part is that this element will have the attribute aria-hidden="true":

<summary>
  <p>
    How much does shipping cost?
  </p>
  <span aria-hidden="true"></span>
</summary>

The reason why I hid this span element is that we’ll be modifying its content with CSS modifying the pseudo-element ::before, and the content we add will be read by a screen reader unless, of course, we hide it from them.

With that said, we can change it because the browser manages the open state of the details element by adding the attribute open to the container. So we can add and change the content using those CSS rules:

summary span[aria-hidden="true"]::before {
  content: "+";
}

details[open] summary span[aria-hidden="true"]::before {
  content: "-";
}

Now, you can add the styling you need to adapt it (remember to use adequate focus states!). You can check this demo I made to see how it works. Test it with a keyboard, and you’ll notice you can interact with it without a problem.

See the Pen Details and summary demo [forked] by Cristian Diaz.

As I mentioned, this approach requires no JavaScript at all, but it’s not the only pattern you can use for markup! If you want to know more about markup for accordion components, you can read this article by Sara Soueidan about this topic.

Skip Links #

Sometimes when you navigate a site, you can find big blocks of keyboard-focusable items, like in a menu, for example. And on many occasions, a user just wants to interact with the main content, so offering a way to skip those blocks of interactive elements is important (especially for switch users!). There is even a WCAG criterion for this case.

“A mechanism is available to bypass blocks of content that are repeated on multiple Web pages.”

— Success Criterion 2.4.1: Bypass Blocks

This is where skip links come into play! Skip links are links that usually will only be visible when a user presses Tab, and it’ll let you go to a page’s points of interest. Normally it’s to take you to the main content, as you can notice on YouTube, for example:

(Large preview)

But there can be multiple skip links in a site that will lead you to various parts of the site, as Smashing Magazine does. When you use the Tab Key to navigate this website, you’ll notice there are three skip links, all of them taking you to important points of the page:

(Large preview)

They’re usually located on the site’s header, but it’s not always the case. You can add them where needed, as Manuel Matuzović shows in this tweet. He added an inline skip link to a project because the interactive map has a lot of keyboard-focusable elements.

Working on a feature that allows users to skip areas with many tab stops (inline skip link). 🔥

Video alt: A page with a bunch of links followed by an embedded map. Pressing the Tab key reveals a link that, when activated, moves focus to the next tabbable element after the map. pic.twitter.com/utSPgzs2Kh

— Manuel Matuzović (@mmatuzo) April 6, 2022

Now, as the usefulness of skip links is clear, let’s create one. It’s very simple; we just need to create an a element that takes you to the desired element:

<header>
  <a class="skip-link" href="#main-content">Go to main content</a>
</header>
<main id="main-content"></main>

Next, we need to hide visually the a element. What I do there is use the transform CSS property to remove it from the visual range:

.skip-link {
    display: block;
    transform: translate(-9999px);
}

Then, we move it to the needed position when the element is being focused:

.skip-link:focus {
  transform: translate(0)
}

And that’s it! Creating a skip link is easy and offers a lot of help for keyboard accessibility.

Tooltips #

Those little text bubbles that show extra information to an element can be done with pure CSS as well, but a little disclaimer here: it is suggested that you can close a tooltip by pressing the Escape key, which it’s only possible with JavaScript. I’ll explain how to add this feature in the second part of this article, but everything else can be done in a very simple way using HTML and CSS only.

A common problem with tooltips is that a keyboard user cannot see them, so we need to ensure the component that triggers it is a keyboard-focusable element. Our best bet here is using the button element. The semantics is really simple, as Heydon Pickering shows in his book Inclusive Components.

<div class="tooltip-container">
  <button>
  </button>
  <div role="tooltip"></div>
</div>

The container with the class tooltip-container is there just to allow us to manipulate the container’s position with the attribute role="tooltip" later using CSS. Speaking of this element, you would think this role adds enough semantics to make it work, but as a matter of fact, it doesn’t, so we’ll have to rely upon a couple of aria attributes to link it to our button.

This attribute depends of what’s the intention of the tooltip. If you are planning to use it to name an element, you need to use the attribute aria-labelledby:

<div class="tooltip-container">
  <button aria-labelledby="tooltip1">
    <svg aria-hidden="true">
      <!--  SVG Content  -->
    </svg>
  </button>
        <div id="tooltip1" role="tooltip">Shopping cart</div>
</div>

However, if you want to use the tooltip to describe what an element does, you’ll need to link it using the attribute aria-describedby:

<div class="tooltip-container">
  <button aria-label="Shopping cart" aria-describedby="tooltip2">
    <svg aria-hidden="true">
      <!--  SVG Content  -->
    </svg>
  </button>
  <div id="tooltip2" role="tooltip">Check, modify and finish your purchase</div>
</div>

Be careful with this approach; use it only to give auxiliary descriptions, not to give information that is absolutely necessary to understand what this element does. That’s because when a screen reader user generates a list of the form elements (including buttons) in the site, the description won’t be displayed unless the user is focusing on the element, as Adrian Roselli shows in his test on aria-description attribute.

Now, it’s time to talk about what concerns us in this article — keyboard accessibility! For this, we need to hide the tooltip and show it until the user is either focusing the pointer on the element or when it’s being focused with a keyboard. For this, we’ll use the :hover and :focus pseudo-classes in tandem with the adjacent sibling combinator.

Additionally, it’s important you can see the tooltip when you hover over it to comply with WCAG Criterion 1.4.13: Content on Hover or Focus. With those considerations in mind, this is how our code should look:

[role="tooltip"] {
  position: absolute;
  bottom: 0;
  left: 50%;
  display: none;
  transform: translate(-50%, 100%);  
}

button:hover + [role="tooltip"], button:focus + [role="tooltip"], [role="tooltip"]:hover {
  display: block;
}

And this is how you create a keyboard-accessible tooltip using HTML and CSS. You can check how both examples of tooltip behave in this demo. Remember, this is not fully ready for production. You need JavaScript to close the tooltip when you press the Esc key. We’ll cover that later in the next part of this article, so keep it in mind.

See the Pen Tooltip demo - CSS only [forked] by Cristian Diaz.

As Heydon mentions in his book, tooltips have a problem when you use them for devices that don’t have a pointer, like cellphones or tablets, then a different approach for them is required. You can use CSS for that using the media queries hover and pointer, as I explain in my article.

Wrapping Up #

Keyboard accessibility is an essential part of accessibility. I hope this article has helped you understand how vital HTML and CSS are to make keyboard navigation a good and accessible user experience. That’s not the end of keyboard accessibility, though! I’ll be covering how we can use JavaScript to manipulate keyboard navigation and how we can use it in more complex component patterns.