Alexandra White on web.dev

All of Learn Accessibility! is available

2023-01-12T00:00:00Z

All modules in the Learn Accessibility course are now available. Written by Carie Fisher, these courses take you through the essentials for building accessible websites and web apps.

You can read them in whatever order you'd like. The final modules on testing walk you through a culmination of all of your knowledge:

The last new module will teach you how to make your forms more accessible. This is a great complement to Learn Forms.

And that's not all. We had four community spotlights with people working on accessibility:

Melanie Sumner told us about her journey into engineering, accessible design, Ember.js, and the importance of funding these efforts.
Olutimilehin Olushuyi told us about his move from the law to web development, building accessible communities, and creating accessible layouts.
Albert Kim told us about mental health awareness, building for invisible disabilities, the COGA Accessibility Community Group, and more practical wisdom.
Elisa Bandy told us about her work for Google's internal documentation, how to prioritize use cases, and building expertise.

We hope you'll discover some new best practices. These modules are meant to build your expertise, but some accessibility best practices differ, based on the disability you're addressing.

We remain open to your feedback. Open a GitHub issue and give as much information as you can so we can address your questions or concerns.

Community highlight: Elisa Bandy

2022-12-13T00:00:00Z

This post highlights a community expert, as a part of Learn Accessibility! Learn more about Google's accessibility initiatives and research.

Alexandra White: I'm lucky to call you a colleague. How would you introduce yourself and your job here?

Elisa Bandy: My name is Elisa, and I write documentation for Google's internal tooling and infrastructure.

Alexandra: That's such cool job. How many people do you work with?

Elisa: Our broader team is about 40 people, and that includes technical writers, instructional designers, and program managers. When I started, six years ago, there were only four people on the team.

Alexandra: What were you up to before Google?

Elisa: During the week, I worked in video game development. And then on the weekends, I worked in shoe repair.

Alexandra: Did you start working in web accessibility once you got to Google?

Elisa: Yes, but not until about a year and a half into it, on the side. I work on accessibility engineering for Google's internal documentation. Before this work, the docs were not designed with accessibility in mind. Any doc feature that was accessible was a happy accident.

There were huge issues, starting with color contrast being entirely inappropriate for links. The tables were an absolute mess—if you zoomed in, everything stayed the same size because it was defined in pixels instead of rem. I volunteered to fix all of those things. And then, I just kept fixing more things. Here we are five years later, and I'm still at it.

Alexandra: You've built yourself to be a person with accessibility expertise and skills, and you've got the resolve to fix the problems that need to be fixed.

Elisa: Yeah, I guess we can say that [laughs]. As a disabled person myself, I know how difficult it is to ask for accessibility considerations. So the fact that we didn't have these accessibility considerations for my co-workers and my colleagues really angered me. And no one else was fixing them. So I went in and I fixed them.

I don't think anyone should have to ask for accessibility. It should be built in from the start.

Prioritize your accessibility use cases #

Alexandra: When you think about web accessibility, there are so many different layers to it, right? There are different, sometimes conflicting needs for various disabilities. How do you prioritize what should be done?

Elisa: A lot of what I do is prioritization. For example, how important is it that some specific use case be 100% totally accessible? I look at a lot of data: what percentage of our population is disabled? How many people have a specific accessibility issue?

For example, there's a subset of users who use ChromeVox, the built-in screen reader for Chromebooks. If something is an issue in ChromeVox, I have to take a look at how many people are using ChromeVox versus Jaws versus NVDA versus VoiceOver.

Externally, not a lot of people use ChromeVox. Because we're Google, a lot of people use Chromebooks as their primary work device, which means ChromeVox is very important for internal documentation. Maybe a ChromeVox bug gets bumped up a little higher than a VoiceOver bug or a NVDA bug.

Generally speaking, I try to fix things for the major screen readers first. Coloration tends to be sort of hit or miss because there's a bunch of extensions that circumnavigate coloration issues, especially for high contrast modes.

Alexandra: You mentioned data, which is incredibly important at Google (of course). We always hear, "Back up your idea with data." How do you collect data for accessibility at Google?

Elisa: I rely a lot on data that's been collected by Google's Disability Alliance. And I'll often cross-check with WebAIM's surveys.

Culture of accessibility #

Alexandra: Tell me about the culture of accessibility at Google.

Elisa: It's grown very, very rapidly into something which has funding and broad-reaching concern. And I have found that almost everyone wants to do the right thing. Our colleagues want educational resources on how to do the right thing, how to prioritize accessibility.

Restructuring an app or a website or anything to be accessible after you've already implemented it incorrectly is hard. So part of my job is getting our engineers to think about incorporating accessibility into the initial designs, before the products are built. People are very receptive to that, even enthusiastic about it!

I've only ever had real resistance to incorporating accessibility once, and even that was fairly easy to resolve.

Alexandra: Can you tell me more about that?

Elisa: When I first joined accessibility engineering, it was only 20% of my time. Some people didn't understand why we were focusing on accessibility. Someone said, "Only 1% of the population is disabled." I stood my ground—we needed to do it because it was the right thing to do. And, it was my time, I'll dedicate it how I see fit.

Of course, it's hard to hear from anyone that disabled people don't matter, that it's too small a group.

Alexandra: Especially when you are a member of that population. Know your audience!

Elisa: I never like to hear, "Oh, this is only 1%." The "only" makes it sound insignificant. But when you think about the global population, that's a lot of people. And that's a lot of people who work at Google. And so many disabilities are under-reported.

Alexandra: We know that far more than 1% of the population are affected by disabilities. WHO reports that over 1 billion people have a disability; and 2.2 billion people have some kind of vision impairment! There's varying severity, of course, and some people with visual impairments wouldn't consider themselves disabled. But these impairments do affect interaction on the web.

Elisa: Exactly.

Build your own set of expertise #

Alexandra: Is there any advice that you wish you had had before you started working in accessibility?

Elisa: It's ok not to know every single thing. Accessibility is a huge, wide expanse of space. I know that there's a lot of stuff that I don't know. I have a very specific set of skills. It just so happens that I know where to find information on what the accessibility best practices are.

Even within my own specialty, screen readers and color contrast, I'm learning new things every day. And I'm deaf, but I'm not an accessibility expert for Closed Captions. I know what works for me, but I don't know what works for everyone else. I'd have to look up best practices if asked.

Alexandra: It's reasonable not to be the absolute expert of every kind of accessibility. How would you help engineers learn accessibility patterns?

Elisa: I work closely with an engineer who's interested in accessibility. I'll hand her a bug and show her how I would fix it. Then, I walk her through the best practice. She may look at other docs and see they recommended one approach, but it doesn't work for XYZ reasons.

The thing about web accessibility is that there's not a lot of concrete code examples, because no two people build the same feature in the same way. So you might jury-rig solutions. Many people don't think about accessibility until everything's been put together. What are you going to do at that point? Are you going to tear it down and put it back together and rewrite all of your tests? No, you're not. You're going to staple something on.

That means you need to understand how a disabled user would expect the application to function, then model your code so it performs that function. It might not look like the perfect code samples or inclusive components, but ultimately, as long as it performs the same function reliably, it's going to be fine.

Alexandra: It sounds to me like you're saying it's more important to get a positive result than to worry too much about how we get there.

Elisa: Yes. Because honestly the ends do justify the means of this case. It's super important to understand how a screen reader user or any other disabled user would expect this to work.

There are a billion ARIA roles, and you cannot possibly know every single one. Further, some don't work with all screen readers! So you need to know the needs of your users to build for them.

Alexandra: Are there common external resources that you rely on when creating internal documentation or offering support to Google engineers?

Elisa: I do rely a lot on the W3C guidelines. They are very good for getting an idea of what you need to do. WebAIM is another extremely good resource that I find to be a little bit better with respect to technical implementation. I also really like the Mozilla docs—nine times out of ten, if I search for something, there's an answer in the MDN Web Docs.

I love inclusive-components.design, which is great if you want a library of accessible components.

Deque University has a lot of best practices. I use it for reference materials, when I'm filing bugs or teaching someone how to follow a specific pattern.

Experience accessibility tools first-hand #

Alexandra: How does one go about learning how a user is affected? Since your expertise is in supporting people who are colorblind and screen readers, let's start there.

Elisa: For color vision deficiency and colorblindness, there are simulators and emulators. You really can't understand how someone else can see until you see it for yourself. If I notice really bad saturation, as soon as I run it through the simulator, I can confirm that it isn't discernible at all.

To support screen reader users, there's no better way to understand it than to actually use a screen reader. Read tutorials first, that's key. Some people get frustrated when they just turn it on and try messing around with it—that's a bad way to learn how to use them. You need more than 5 or 10 or 20 minutes. Use it for an hour at minimum to reveal some of the frustrations users face who rely on this technology.

I'm a firm believer that everyone is going to need accessibility technology at some point in their life. For example, I recently hurt my wrist and couldn't use my mouse, so I used a keyboard for multiple weeks. It was so frustrating. These sorts of exercises can really help put you in the position of a disabled person trying to navigate a world of able-bodied people.

Simulators, while useful, are not equivalent to a disability #

Alexandra: Obviously the experience that I have, or any developer would have, using simulators is not the same as someone with a visual impairment.

Elisa: You can always talk to someone who is disabled, to learn about their experience. And when you're building that empathy, it's important to remember that a person who frequently uses these tools is always going to be better at it than you. Disabled people are always going to be better at navigating their own spaces, because that's the body that that person lives with.

My fear is that people who go through these empathy exercises, for lack of a better term, think that they know precisely what people go through. They suddenly think they're the expert on that experience. You're not the expert on that experience. If you're able-bodied, you're fundamentally not the expert on screen readers. I'm not an expert on being colorblind, even though I work in this space. I'm not an expert on screen readers.

I am an expert in my experience of being hard of hearing. I am an expert on needing a hearing aid and navigating my own experiences every day. But that doesn't mean I'm an expert in other people's experience with deafness

The worst thing you can do in accessibility engineering is have an ego. No matter what you do, you're going to mess something up. That's not something to get discouraged about because no two people have the same disability needs. No two people have the same viewpoint on accessibility and disabilities. You cannot do everything 100%—but that doesn't mean you shouldn't try. You won't ever be perfect, but strive for it anyway.

You may get critical feedback, someone may say, "Hey, your product is not accessible!"

Alexandra: Simulators support a different learning style, demonstrating your product while facing some of the problems that disabled people may experience. But, that's not the same as experiencing your product with the accessibility tools they use every day.

Elisa: Do I get mildly annoyed when people turn the sound off and read captions and then suddenly realize, oh, these automatically generated captions are terrible? Yeah. That's not how I experience captions. Some disabled people see a person emulate their experience and complain about the tools, without actively needing those tools. That's frustrating, I really get that.

But I also don't want to be the person who has to sit there and describe my experience as a deaf person over and over and over and over and over again. Every single time. If we want able-bodied people to understand our experiences, we're going to have to put up with their reaction to the experiences.

That said, the "experiences" like blind restaurant dining and wine tasting, those make me mad. That's like cosplaying a disability. But in the interests of trying to understand how your users use a feature or how readers read the page? That's fine. In fact, that's the minimum. Put yourself in their shoes for an hour and figure out how these things actually work. It really does matter.

Figure out how people navigate on your site. You may wonder, "Why can't I just put a banner warning at the top that all the links open in a new tab?" Well, because someone might not be reading the page starting with the banner. Build your design with disabled people in mind.

Do one thing: stop building infinite scroll #

Alexandra: Is there one thing you wish that engineers would just start doing to make their sites more accessible?

Elisa: Infinite scroll is a blight and no one should ever use it. I can't find things, I need to be able to find things! And, it's so bad for performance.

Also, moving things around visually and within the DOM is really annoying. The tab order matters, especially for keyboard users.

Learn more about Google's accessibility initiatives and research. In addition to the web development resources at Learn Accessibility, Google has created an accessible documentation course: Tech Writing for Accessibility.

Follow Google's Accessibility team on Twitter at @GoogleAccess and the Chrome team at @ChromiumDev.

Accessibility Week

2022-11-18T00:00:00Z

This week we highlighted accessibility resources to help you make your sites and applications usable by everyone.

We're continuing to roll out Learn Accessibility, a brand new course written by Carie Fisher that will take you through the essentials for building accessible websites and web apps.

We've had 3 community spotlights:

Melanie Sumner told us about her journey into engineering, accessible design, Ember.js, and the importance of funding these efforts.
Olutimilehin Olushuyi told us about his move from the law to web development, building accessible community, and creating accessible layouts.
Albert Kim told us about mental health awareness, building for invisible disabilities, the COGA Accessibility Community Group, and more practical wisdom.

Watch us answer your questions #

On Thursday, Alexandra White spoke with Carie Fisher and Melanie Sumner about accessibility, and we answered some of your questions.

Have more questions? Ask us on Twitter, @ChromiumDev.

More resources #

A solid document structure is a great start for accessible development. Find out how to really use HTML in our Learn HTML course. Follow it up with Learn Accessibility's Content structure module for more on semantic HTML, landmarks, and tables for accessible content.

In Testing web design color contrast get an overview of three tools and techniques to ensure your content is readable by everyone.

In Building the main navigation for a website learn how to create accessible navigation using semantic HTML.

On the web #

The W3C hosts a collection of courses, training, and certification on digital accessibility from different providers.
Read Accessibility articles on Smashing Magazine, including <article> vs. <section>: How To Choose The Right One by Olushuyi Olutimilehin.
If you're making a case for accessibility work at your company, check out Melanie Sumner's pleasefunda11y.com.
If you want to support the Cognitive and Learning Disabilities Accessibility Task Force, join the COGA Accessibility Community Group. This group supplies user needs and feedback to the COGA Task Force.

Community highlight: Albert Kim

2022-11-17T00:00:00Z

This post highlights a community expert, as a part of Learn Accessibility!

Alexandra White: How would you introduce yourself? You do so much accessibility work.

Albert Kim: I'm a digital accessibility subject matter expert (SME), a UX design consultant, and a public speaker and coach, raising mental health awareness in the tech community.

I founded Accessibility NextGen, a community for people interested in learning more about accessibility. I'm a Disability:IN NextGen Leader. And currently, I'm a W3C invited expert for the Cognitive and Learning Disabilities Task Force and Mental Health Sub-Group. Lately, I've been researching how to include people with OCD, ADHD, dyslexia, and PTSD into the product development process.

Offline, I'm a DEI community leader, blogger, huge foodie, photographer, and I love traveling—I travel a lot. I'm the first generation in my family to live abroad, the first generation to get any formal education. I was raised by a single mother in a low-income household. I'm a military veteran.

I identify myself as someone who can empathize with a lot of different struggles and life stories.

Alexandra: Did you always think you'd be someone who would have a career or work in accessibility?

Albert: I always wanted my profession to be not just a job, but one with social impact. I've switched careers several times. In college, I tried different majors. I've founded startups, I was a business development manager, I worked in telecommunications in the military. I was an interpreter. I've had many different jobs.

It's important to mention all of these different experiences, as all of the dots began to connect in their own way. I eventually got into digital accessibility because of my personal experience as someone with a disability, but also with a love for digital products. I really, really love a good product. Useful, functional products.

We often use the phrase "assistive technology," but all technologies are assistive. I'm passionate about digital products that help improve my life, that make my life easier. I want to connect consumers with the producers of digital products, and digital accessibility is fundamental to that connection.

Alexandra: Can you expand more on how you create opportunities for direct communication between users and product creators?

Albert: Often, when developers build digital products, they don't make full use of their own product. They aren't aware of how useful their product is for users, especially those with disabilities. That means that they're not thinking about those use cases in the design process. Because of this, they often miss an opportunity to discover disabled users who could become loyal customers.

Designers and developers may or may not find out later that what they built is useful to disabled users.

Connecting product owners and developers to their users with disabilities early in the product development process can lead to full realization of a product's potential. This is in addition to products designed with accessibility as an intentional feature.

As a metaphor, I love sharing good food with my loved ones. The joy is doubled when I can share it. Just like that, I want to share really good products with my friends, but I cannot always share them if they're not accessible. A blog post alone, without a screen reader or other interventions, is not accessible to my blind friend. If digital product makers hear these stories from users, then hopefully they'll make accessible design choices so the users can fully utilize their products.

Build for "invisible" disabilities #

Alexandra: I appreciate that you mentioned your blind friend specifically, because often the first thing that comes to mind when developers and designers do think about disability are the "obvious" ones: visible and often permanent disabilities. But there are so many people impacted by accessible design, such as those with temporary and invisible disabilities, like psychological disabilities.

You're an invited expert to the W3C group, the Cognitive and Learning Disabilities Task Force and Mental Health subgroup. What is COGA?

Albert: The COGA task force is a joint commitment of the Accessible Platform Architecture (APA) Working Group and the Web Content Accessibility Guidelines (WCAG) Working Group. COGA assists these other groups in creating guidance documents, as well as updates to existing W3C accessibility guidelines. For example, we further developed proposed success criteria for WCAG 2.1.

We've built a repository of user research to serve as supplemental guidance and have published issue papers.

Often, companies and developers look at WCAG guidelines as their standard for web accessibility. But, there's supplemental guidance in the form of issue papers. COGA has written some of these papers on different use cases to help describe cognitive disabilities and scenarios where persons with atypical profiles use technology successfully and unsuccessfully. We help these working groups think about cognitive disabilities and learning disabilities.

Alexandra: Have you been with COGA from the start?

Albert: I joined a few years after the group was developed; but after I joined, I strongly advocated for a mental health subgroup. COGA's focus was primarily on cognitive and learning disabilities, but I wanted to start a conversation about mental health.

I happened to know someone in that community who reached out on Twitter. I got in through that connections, and I'm very passionate about bringing invisible disabilities into web accessibility spaces.

Participate in COGA and other W3C initiatives #

Alexandra: Can anyone participate in such a group, and do people attend regularly?

Albert: It's an open group! Anyone can join, as participants of either the APA Working Group or the WCAG Working Group. If your company sponsors the W3C, you can join, or as an independent invited expert. I'm an independent invited expert.

Alexandra: For most of my career, I didn't know that. I didn't realize how much power an individual could have in influencing and even creating standards that make up the web.

Albert: It's definitely a big time commitment and a lot of responsibilities. For some, that may not be feasible.

The easiest way to participate is to join the COGA Accessibility Community Group. The community groups are more flexible and don't have as much responsibility or commitments. This group supplies user needs and feedback to the COGA Task Force.

Alexandra: Here's where I confess my own stakes in this work, in your subgroup. I suffer from anxiety and depression, and have for most of my life. There are times I'm overwhelmed by certain sites and apps, even those which are meant to help us be "productive," as some tasks have long checklist steps before you can move to the next task. Tools which are helpful on my best days can be overwhelming the next day.

In your Accessibility Rules interview, you mentioned the ways in which endless scroll can be traumatic, and how that affects you as a person with OCD and PTSD. Is there guidance out there or sites that are doing a good job of giving people a way to opt-out of an experience that may be triggering.

Albert: There is a COGA issue paper, that has supplemental guidance. As far as websites or resources acting as a good example… that might be hard to find! Addressing mental health in web development is still very new. But I do have a lot of advice and specific best practices that I can recommend as a user with disabilities and as an accessibility SME.

First thing, follow the WCAG guidelines, though most of them were written prior to the mental health subgroup existing, so much of that guidance is helpful beyond those with physical disabilities. It's helpful for users with invisible disabilities and mental health disabilities. Following this, that has to be the beginning. If websites were following these guidelines and did a really good job, even if they didn't think about mental health at all, we probably wouldn't experience many of these problems.

One of the most important design choices that would be helpful is clear, semantic structure. Clear headings can be very helpful for users with OCD, ADHD, or dyslexia. Even for me, and my anxiety as well. All of these illnesses share some pain points, they're interconnected.

Stop creating bad user experiences #

Alexandra: Okay, what about the opposite? What are people building that is against WCAG recommendations that is causing problems for those with mental health issues?

Albert: So many things:

Complex navigation and page layouts that are difficult to navigate and use.
Multi-stage forms that have a lot of imposed requirements, rather than communicating with users why something is important or needed.
Long passages of complex text with a lot of jargon or metaphors that are difficult to understand, which require additional context.
Flickering content or background images that are moving or blinking. Notifications that you can't turn off easily.
Timeouts on complex activities, especially without options to save, such as when you're filling out a form and you're given a warning or a timeout after 30 seconds.
Search on websites that doesn't work well. This may mean there's a lack of filters, and that leads to an endless set of results.
Unexpected behavior, like when you click a button and the page jumps back to the top so you have to figure out where you were and scroll back down.
Hidden actions, like when a cookie popup requires multiple steps in really small print to decline the cookies. Or deliberately making subscriptions that are really hard to cancel.

These aren't just accessibility issues, these are usability issues.

Alexandra: Good product design is accessible design.

Albert: There are so many examples. Make a good product and users will come back. These are just some examples.

Include content warnings #

Alexandra: Something often politicized, at least in the United States, is the idea of content warnings (colloquially known as "trigger warnings").

These warnings may be related to a design choice—flashing images may cause seizures. Those are less controversial, and fairly commonplace. However, content warnings for certain subjects is also critical for many.

Albert: If your content has something sensitive, such as violence or mentions of sexual assault, having warnings can be very helpful for users with PTSD, depression, and anxiety, especially as it may stem from personal experience of traumatic events. Allow for customization and personalization that is obvious, so people can choose what information they are ready to read, see, or hear.

The core meaning of the web is to relay information. Rather than imposing our information, we should be communicating it. We should think about how others will perceive what we have to share. I may write something one way, but it may be interpreted by someone else in a different way. Clear structure helps to avoid some of these miscommunications.

Summaries and tables of content are also very helpful in allowing a user to prepare themselves for what they'll be learning.

Alexandra: I'm personally grateful for these content trigger warnings, so I can decide if I'm in a place where I feel comfortable reading or seeing content which may lead to an emotional reaction. For those who are worried that there may be pushback on including trigger warnings in their content, do you have any advice?

Albert: We must think of it as a public health issue, not a political issue. Trigger warnings are not about censorship, at all. It's about giving users freedom to choose. When we don't provide the option, then we don't give users freedom to protect themselves from something that may cause harm to their mental health.

We shouldn't arbitrarily impose or force information on users. The most common reaction for people with PTSD who encounter trigger content is to leave and never come back. You lose those people. It's a health issue.

Albert: There's some similarity between a trigger warning and a parental control. We don't have any political concerns about letting parents choose what is acceptable to be seen by their children. It's very conventionally understood. This is exactly the same. People deserve to have control for themselves.

Alexandra: Seems reasonable to me!

Do one more thing: communicate clearly #

Alexandra: If you asked developers to change one thing about the way they design and build websites to make them more accessible, what would you ask for?

Albert: Don't forget that the fundamental purpose of a website is to clearly communicate information to the user. To do this, you must think about what information you want to share with your users, and more importantly, how to frame that information so the content and your intentions are understood.

You can succeed by building each page with semantic HTML, use a clear structure and layout of content. Clear structure and layouts help you communicate better with your users, and are more scalable, usable, and accessible. Ensure labels are consistent and instructions are provided correctly. This helps users more easily find the information they seek and better understand the relationships between different parts of the content.

This advice touches upon three WCAG success criteria:

Missing these success criteria is among the most common accessibility issues found on websites. This affects people who use assistive technologies (such as screen readers), but also neurodivergent people who may have cognitive and/or learning disabilities or mental health conditions.

Keep up with Albert's work on Twitter as @djkalbert. Check out Accessibility NextGen.

Community highlight: Olutimilehin Olushuyi

2022-11-09T00:00:00Z

This post highlights a community expert, as a part of Learn Accessibility!

Alexandra White: How'd you get started with web accessibility?

Olutimilehin Olushuyi (Shuyi): Okay, so, it's a funny story. I'm a lawyer. I realized in my final year of school, I didn't want to practice law for the rest of my life. So, I tried to drop out of school, but my dean and "school mother," Professor Ayodele Atsenuwa, said, "Let's talk about this. You're in your final year—just finish it."

Ultimately, I'm happy she said that, and I'm happy I finished, because it's been helping me in my accessibility work. Professor Atsenuwa asked me what I wanted to do instead, and I had no idea.

I started to look up new career opportunities, and got in touch with some people who wanted to build a startup and needed a lawyer. That opportunity wasn't the right fit, but that was the first time I knew people wrote code for all of the products we use. I thought, "I can pick this up." I started to teach myself HTML and CSS. Then, I got to JavaScript and … [laughs] JavaScript did JavaScript things, so I went back to focus on my front-end semantic languages.

I came across the work of Andy Bell and Heydon Pickering. I purchased Every Layout, and it changed my life. Andy kept mentioning accessibility, but I didn't know what that meant in this context. I realized I may be able to work in web development without needing to know how to write JavaScript!

I reached out to Heydon and he was very receptive, very responsive. It seems everyone in the accessibility field is that way, and I'm grateful for that.

Alexandra: I'd definitely agree, everyone I've spoken with has been so kind and so helpful.

Shuyi: Absolutely. Currently, I do a lot more work in advocacy. I'm based in Nigeria, a country where web accessibility is not mandated by law. The Discrimination Against Persons with Disabilities Act passed sometime in 2018. But there's no web accessibility law, only law about physical accessibility. It's like the USA's Americans with Disabilities Act (ADA). Our law is poorly structured, but better than nothing.

I realized if I'm going to have any chance to make a difference and become an accessibility focused developer, first I have to make the ecosystem aware of accessibility needs. I started tweeting about accessibility advocacy. I talked to companies and brands, whose buy-in is needed to get accessibility to work.

Alexandra: I bet your legal background is incredibly useful in working with accessibility. You can actually read the new legislation and understand it in a way that the average person won't. That includes an average developer.

Shuyi: I think one of the biggest gifts from my legal background is that I can sit through unending pages of background materials, really lengthy documents, without getting tired. I just fold my legs, put my laptop up, and start to read. And read. And read. It's got advantages,

Alexandra: I mean … I'm jealous, that's a great skill to have. Do you think you'd ever work with the government to get a digital accessibility law passed?

Shuyi: I'll be honest, I don't think so. Engaging with the government is a different ball game. It takes too long to get our government to do something, especially as an individual. That kind of work is better for NGOs and other organizations with staffing and resources to bring about change.

The physical law took so much time to pass, and accessibility needs moved far beyond what ended up in the law years ago. It's like the first draft was passed even though the world has changed.

Ultimately, we're happy there's something to rely on, no matter how outdated it ended up being. There is a law to enforce.

Create accessible layouts #

Alexandra: I read your article, <article> vs. <section>: How To Choose The Right One in Smashing Magazine and the Twitter thread that inspired it. What would you say is one big takeaway, what's the one thing you want from web developers?

Shuyi: Developers must read the content before they begin building layouts.

Originally, for my site design, I had just counted the number of paragraphs and put them in sections and articles, without much thought. But, someone drew my attention to the misuse of sections—it was the first time I thought about it. Reading the content is one thing you can do to make a better product.

Alexandra: When I was a developer, I often had freelance clients say, "Oh, just build something for us and we'll fill the content in later." And sure, there are some pages that have automatic context, like a contact page. But knowing how many pages to build, and what kind of custom support was needed, that could only be answered when I got the content.

Shuyi: Before knowing what I know, my best client would give me general design ideas, and I'd built out a site with a bunch of lorem ipsum. I'll figure all that stuff out. But, when you realize how much the content infrastructure affects users on the web, you realize just how much of the standard process for building things on the web is actually flawed. You must be intentional when you build things.

So much accessibility infrastructure work doesn't get attention at all, and it breaks my heart.

Alexandra: How did you do your research to make sure the advice you gave in the article was correct?

Shuyi: First, I separated the sources of information—that's something you do in law, separating primary and secondary sources. The primary sources are the actual law (like the ADA and Nigeria's laws) and the secondary sources are what experts interpret from the law.

I decided to refer only to the primary sources: the HTML, WCAG, and WAI-ARIA specs. I read other people's works, a lot of good work. But, at the end of the day, the opinions were so divergent, I decided I could only take them as useful context but not rely on them as having the right answers.

Build an accessible community #

Alexandra: You mentioned trying to shape your Twitter feed into a place for accessibility. Have you had many other conversations on Twitter since the Smashing Magazine article's publication about what you learned?

Shuyi: For the first couple of days, I couldn't make good sense of Twitter. So many people followed me, like 200+ people. At first I was excited, but then I was scared. Like, I'm just starting out, don't follow me for a bunch of sage wisdom. I was added to a lot of Twitter lists.

But like, I'm a person. I tweet about a lot of vague, non-accessibility, non-web developer stuff. I don't want to let people down. Don't follow me just because of accessibility! I'll feel like I'll let you down.

Alexandra: [laughs] I mean, I think a lot of people think that. I certainly do about my Twitter persona.

Shuyi: Most responses to the article itself were positive. I got one response to the article which was a bit controversial. Vitaly was my editor, and he reached out directly to share the comment and asked me to investigate. Turns out, the person was referencing the MDN docs which said that all articles should have a heading element. I recommended that the section should have a heading element based on the specs.

The MDN docs recommend including the header but don't really explain what the benefit is.

The spec changes less frequently than user needs, of course, so as long as you can back up your decision to change the way you build something, it's probably okay.

So, let me give an example. Let's say you're building a card component called "Prices," with three elements in it. Hayden Pickering would suggest putting each card into a list element. That way, when someone using assistive technology (AT) gets to that section, it's announced to them that there are three items in the price list. You can style the list so that there are no bullet points, make it look however you want, but it helps AT users get the useful information first. If you wrapped each item in a div, you'd just be focused on the visual aspects, which doesn't help visually impaired users. Think of people before design.

I took that idea, and transposed it for a blog page. The blog posts are actually within a list element. That way, on entry to the page, the user is alerted that they are at one of some number of posts on the page.

So, I stood by my recommendations in the article, and I will until I understand why MDN makes the recommendation.

Alexandra: Since the MDN docs are open source, will you suggest changes and make updates there?

Shuyi: I'll be honest, I haven't yet made any open source contributions. But, this is the kind of work I would like to be doing, certainly more than working with the government.

Spec versus implementation #

Alexandra: It sounds like one big takeaway is that sometimes the spec says one thing, but implementation and other external docs may suggest doing something different. How does someone decide whose advice to follow?

Shuyi: I think about this a lot. I'm not sure I have the required experience to answer that question. We're always trying to future-proof. It's good to make continuous enhancements as the web changes. That way, when the spec is updated, you don't need to retrofit your site. What are the chances that you make a choice and three years from now the spec changes.

Every choice we make now is our best guess of what we think the future of the web will look like, what direction we think the spec writers will go.

Alexandra: The web is constantly changing, one person can't have all of the answers! Did the specs go through changes while you were writing?

Shuyi: I started writing my article before the document outline model was removed from the spec. This model suggested that heading levels should be automatically calculated based on how deep the nesting was. But it was never really implemented and that created a lot of issues for developers. The advice to developers was to manually fix their headings.

If the article had been published before the spec change, I probably would have gone back and made that edit—it is in Smashing Magazine after all. But if it had lived on my personal blog, would I have? Probably not. And that's just talking about updating an article, not updating an entire website that's built based on a changing spec.

Do we expect developers to immediately change their websites when the spec changes? Of course not. They make calculations as to what's best when they're building their sites and live with those choices. The specs will change, the specs may not have the answer.

Accessibility as a career #

Alexandra: How much of your time do you spend thinking about global accessibility standards? Standards and laws are different around the world. I'm sure you've read a lot of them, and I'm sure some laws tell you to do the opposite things. What would you do in those cases?

Shuyi: I thought about launching a business for freelance accessibility work. I went into a global web accessibility chat channel and asked for tips on how to get started. Adrian Roselli reached out and said, "Your clients will be relying on you to keep them compliant with laws which could have major consequences. Before you offer your services, know what region you have expertise in. Know what laws you're familiar with so that, while you're making a living for yourself, you don't leave clients with huge liabilities. They trust you to know the law."

Of course, so many businesses are seeking accessibility help because they are legally required, and not just because it's the right thing. Capitalism is the reason accessibility is being implemented. At the end of the day, it doesn't matter why it happened, it matters that the product is accessible.

I put a pause on freelancing until I have full confidence that I can help clients with the laws of their region. Standardization is critical, the efforts and impact of WCAG cannot be overstated. Having a central framework of how the web should work makes it easier for governments to rely on the same standard. But of course, not every government will accept those standards.

Alexandra: You've gotten a lot of great advice from great people in your journey into accessibility. Is there any other advice you wish you'd gotten before you decided to pursue this as a career?

Shuyi: While it wouldn't have changed my career path, it would have been nice to know that as noble as accessibility work is, it's greatly affected by capitalism.

Alexandra: [laughs] Oh yes.

Shuyi: And I'm a junior. I have a year of experience in accessibility. Especially if you're based in Africa, like I am, there's a limited availability of positions in accessibility. Companies are hiring managers, one person to meet whatever legal requirements are needed. But I want to work on a team, where I can learn and build skills.

I was so excited to get to work without learning JavaScript—that I could just learn the rules and help my team apply them. But the developer positions at agencies require that I have JavaScript experience. I moved to a new city and joined a JavaScript bootcamp so I can meet those requirements. For anyone else on their accessibility journey, know that you must focus on building your development skills first.

I'm not going to lie, I still don't like JavaScript.

Do one thing: add keyboard focus #

Alexandra: [laughs] Is JavaScript the reason I'm now a tech writer instead of a developer? Yes. Yes, it is. I hate it so much. I wish you the best of luck in your boot camp.

What's one thing you want developers to do to make their site accessible?

Shuyi: Keyboard focus. I am begging from the bottom of my heart. My trackpad currently doesn't work, so when I'm on the go, I rely on my keyboard to navigate the web, and almost every website is horrible. Keyboard focus doesn't just benefit disabled people.

Building accessible platforms benefits everyone.

Keep up with Shuyi's work on Twitter @shuyiolutimi.

Community highlight: Melanie Sumner

2022-10-06T00:00:00Z

This post highlights a community expert, as a part of Learn Accessibility!

Alexandra White: Thanks for joining me! Who you are and what you do?

Melanie Sumner: My name is Melanie Sumner and I am a software engineer specializing in digital accessibility. I've been writing code for the web for 25 years. My first career was… kind of a spy. I was an intelligence analyst in the US Navy, and coding was my hobby.

I didn't really like being a spy. I wasn't fond of death, it turns out. As most people are not, when they have to be closer to it. I had to decide what I wanted to do next, and it was time to turn my hobby into my career. In the last 10 years, I've really focused on software engineering in the accessibility space, specifically.

Alexandra: You don't often hear, "Oh first I was a spy." No big deal. What brought you into accessibility work?

Melanie: I was working at the University of North Carolina [UNC] Chapel Hill at the time, in the Department of Development. They don't mean development like web development, they mean development like fundraising.

My direct manager had a vision impairment, and he had to zoom everything to 400% to see it. He was a fantastic software engineer. Probably the best manager I've ever had, actually. But he was always breaking my stuff, because he would zoom in to look at my work. If I hadn't thought about building things responsively, they would break.

My manager's boss was blue colorblind. I don't know if you know what UNC blue looks like, but it's this light sky blue color. And they loved using it on white.

Alexandra: (laughs) Oh no.

Melanie: His boss was always complaining that he could never see my work! I had to develop a set of complementary colors and a color scheme for our sites. That got me thinking about color contrast and thinking about how people who are colorblind (or otherwise visually impaired) use the web.

Because UNC is a state university, there's a US federal requirement to conform with WCAG accessibility level AA. We aimed for level AAA because it's an education institution.

As I learned more about the state and federal requirements and began reading the W3C Accessibility spec, I thought, "All of this makes sense." Most of the web wasn't compliant, from what I could see. Of course, people have been working on web accessibility for as long as the web has existed. Sometimes JavaScript engineers (in particular) are a little slow on the uptake when it comes to digital accessibility.

I call accessibility the final frontier of the web. Lots of good people work on automation for accessibility—and we need to work on solutions the same way that we've approached other hard problems, such as performance and security.

Alexandra: You've probably read a lot of long complex documents, in the Navy and at UNC. Did you find it was challenging to understand the spec?

Melanie: I had to read it about five times before I understood it—and I'd read other specs before. I always tell people, don't feel bad if you don't understand it, because I had to read the spec five times! I'm not even joking.

It takes a lot of time to get used to spec language. And if you don't interpret it correctly, you might do the wrong thing. Also it's important to understand that a lot of the spec language is meant for browser developers. Look for "authors should," because that's a reference to web developers.

Alexandra: A lot on the web could be better if more developers knew how to decipher the specs.

Melanie: There's a lot to be said for sites that do that interpretation for you. I built a11y-automation.dev and that site is kind of like my baby, my side project. I try to itemize every accessibility violation and link it to the WCAG success criteria in question. If there's automation to prevent the error, I'll offer that solution.

You could familiarize yourself with the list of potential violations, but more important is learning how to fix it. For automated fixes that don't exist, maybe you're inspired to write a linter or a template—maybe you get inspired to write some kind of test.

I prefer to work in open source, because you get to kind of riff off each other, offer an improvement (sometimes an improvement, sometimes not, but we all try our best). We build on each other's stuff, and then we end up with this really great outcome for the web.

How to fund accessibility #

Alexandra: I was really drawn to pleasefunda11y.com. It's really important to get developers to learn how to build accessible sites, but they won't always have the resources without having executive leadership funding and approval. Why did you decide to build this site?

Melanie: I was frustrated because accessibility is so underfunded. All of the open source funding seems to keep going to CSS. And I love CSS, we can do so much with it.

I built the site because Addy Osmani—a Chrome software engineering manager—reached out and said he saw I was asking for accessibility funding, but he wanted advice on what specific work could be funded. That's a big problem: open source funders want to give money to specific projects, not general ideas that have no determined outcome. I took some time to write down some specific initiatives, what's needed and how they'll help make sites accessible.

Even if companies build towards these efforts without me, we could move accessibility on the web forward in a really significant way. It's a very small spend by comparison to other web efforts, and it would have a huge impact on people's lives.

The current way of thinking is often, "Well, how many people have a disability?" It should be: "What is any person's relationship to their technology?"

And some folks have told me, "Well, I don't think color blindness is a disability." You may not identify yourself as having a disability if you're colorblind, but it does affect your relationship with technology.

15 _%

people self-identify as disabled.

_Source

253 _m

people with visual impairments.

_Source

countries with web accessibility law.

_Source

Learn more about the statistics in Learn Accessibility's first module: What is digital accessibility, and why does it matter?

Alexandra: Tell me more about understanding your relationship with technology. How does that relate to accessibility?

Melanie: For example, if you are neurodiverse, maybe you need really simple language and very clear directions. You may be better served navigating through three or four screens in a flow, making a few choices at a time until you get to the end. There's not good guidance for modern technical applications.

We have whole companies that do devops, and if you try to use some of those websites, you're like, "Oh my god," you know? We try to pack the kitchen sink into all of our interfaces these days.

Alexandra: Can you share an example?

Melanie: For example, GitHub has dropdowns with nested tabs. And [exasperated sigh]. I can't get upset (even if I'm frustrated). The modern web has to grow to meet new demands. But we also have a responsibility to build in a way that doesn't leave people behind.

That's what drives me, that's my passion. I don't want somebody to not be able to get a job because the tools they'd have to use at the job are not accessible.

Alexandra: One hundred percent. And people often think about building accessible products for their external users, but not necessarily thinking about their employees.

Melanie: I thought, you know what, this funding advice would probably benefit everyone.

I hear from engineers all the time that they'd love to do accessibility but "my company doesn't care." I bet they do care! You just need to bridge the business logic gap. Show them the beneficial outcome for the business. The site is open source, of course, and I love contributions and edits.

Alexandra: Accessibility is often left to the end of the process, like, "Oh we can just make this accessible later." But it's going to take a lot more time to add it later than it would to integrate accessible practices throughout the project.

Melanie: I often say, "Do you want to pay to build it once or do you want to pay to build it twice?"

Ember.js and the core accessibility team #

Alexandra: I know you're also involved in the Ember.js framework core team. How did you get involved?

Melanie: I was hired to work at JPMorgan Chase, on their corporate investment banking platforms. Ember is a heavy duty JavaScript framework used when you need a really stable (maybe even kind of boring) base, that can help you avoid writing code that loses a lot of bank dollars. Ember has a backwards compatibility guarantee—you can upgrade every time, even if you hit a major version. We really try to do things incrementally, so it doesn't break your app.

Anyway, I showed up to an Ember conference, and I met a bunch of people in the community. Ember folks were so kind. And there's a really strong code of conduct that I just hadn't seen yet in other places.

When I got out of the military, I wanted to go into security. I went to an infosec meetup, and didn't see any other woman there. One of the older guys looked at me and said, "Are you sure you're in the right room, sweetheart?"

Alexandra: [Groans] It hurts. And it's completely unsurprising. I've experienced something similar.

Melanie: I want to say this was 2011, maybe 2012? The landscape has changed a lot. I stayed that night, through that meetup, to prove a point. I wasn't gonna let that comment shut me down. I cracked jokes, took good notes, and participated in the conversation, so people knew I was there. I feel like a lot of my career has been proving men wrong.

But, I don't want women to become software engineers just to prove men wrong. I wanted to be a software engineer to build amazing things, because it's fun to do. Women should have that career option.

Alexandra: Absolutely.

Melanie: I shared what I knew about accessibility with the Ember community, because obviously as a banking platform, you have to conform to the US federal requirements. Yehuda Katz and Tom Dale said, "We have a gap on the team. We have a lot of JavaScript experts, performance experts, people out-of-this-world smart, and we need someone with accessibility knowledge." And they invited me to join the core team.

I'm working on initiatives to help make Ember accessible by default. That means when you say ember new <my-app-name>, you should immediately pass WCAG success criteria.

Alexandra: I saw a long list of accessibility tools for Ember on GitHub. Have you found that people in the Ember community are excited to contribute to those tools?

Melanie: That's been a really exciting part of this work. I wrote accessibility linting rules for Ember while working at LinkedIn. Then I left LinkedIn to work for Hashicorp, and other folks are still contributing to the linter because it's useful for them. That's the part of this work that gives me chills and gets me excited.

We accept that, as a baseline, accessibility is a civil right. That's not up for discussion.

What we discuss is: What can we implement? When? How do we make it? How do we teach this and make it backwards compatible? How do we help developers provide accessibility support without a huge extra feature that they have to build or plan for?

Alexandra: Accessibility is a civil right. That gives me chills! It should just be a thing we all know as truth.

Melanie: I've had people say uninformed things to me, like "I wouldn't use the internet if I was blind." Or, "Why do I have to think about disabilities when it's only 5% of my users, when it's working for 90% of my users?" I won't have those discussions, because they're often used to distract from the work.

When you write accessible code, you're going to get performance boosts because you're thinking about building sites informed by W3C specs. You'll use the semantic HTML instead of just divs, and you'll use headings. You'll choose a <button> instead of adding a click event to a <div>, and you'll get performance enhancements.

Do one thing: automate accessibility #

Alexandra: What's one thing web developers should do to build accessible websites?

Melanie: Add automation. Start with an existing linter for whatever framework you have, whatever kind of code you're using. I don't care which one you use! Your build should break if one of those rules is broken.

Some things can't be automated, because AI can't yet decipher intent. For example, an image's alt text value should be meaningful, but what does that actually mean? Right now, a human needs to discern that, and not automation.

But an automated tool can tell you, "You're not passing color contrast." Just fix it. Don't fight it, don't say, "But I don't want to, I prefer it this way." This is not about you. It's about making what we do available for everyone in the world every day.

Accessibility is a journey, and you're always going to be learning. I've been specializing in accessibility for over a decade, and I'm still learning new things all the time! Don't be defensive, just do it.

Keep up with Melanie's work on her website at melanie.codes and Twitter @a11yMel. Check out her accessibility resources on pleasefunda11y.com, a11y-info.com, and a11y-automation.dev.

Introducing Learn Accessibility

2022-09-30T00:00:00Z

Today we are excited to announce a new addition to our series of courses on web.dev. Learn Accessibility is a brand new course written by Carie Fisher that will take you through the essentials for building accessible websites and web apps.

Seven modules are launching today, and the rest will follow in staged launches through the end of 2022.

Read them in whatever order you'd like, and we hope you'll discover some new best practices. Even with our accessibility experts, we're constantly learning about new tools and new techniques to make our sites the best they can be. Some accessibility best practices differ, based on the disability you're addressing. It's important to understand your users and to listen to people with disabilities when they tell you what they need.

Learn Accessibility joins our existing courses:

We are open to your feedback. Open a GitHub issue and give as much information as you can so we can address your questions or concerns.

Coming up, we'll also have a series of interviews with various people working in accessibility. Follow this space to read their insights.

Yahoo! JAPAN's password-free authentication reduced inquiries by 25%, sped up sign-in time by 2.6x

2022-05-10T00:00:00Z

Yahoo! JAPAN is one of the largest media companies in Japan, providing services such as search, news, e-commerce, and e-mail. Over 50 million users log in to Yahoo! JAPAN services every month.

Over the years, there were many attacks on user accounts and issues that led to lost account access. Most of these issues were related to password usage for authentication.

With recent advances in authentication technology, Yahoo! JAPAN has decided to move from password-based to passwordless authentication.

Why passwordless? #

As Yahoo! JAPAN offers e-commerce and other money-related services, there's a risk of significant damage to users in the event of unauthorized access or account loss.

The most common attacks related to passwords were password list attacks and phishing scams. One of the reasons why password list attacks are common and effective is many people's habit of using the same password for multiple applications and websites.

The following figures are the results of a survey conducted by Yahoo! JAPAN.

50 _%

use the same ID and password on six or more sites

60 _%

Use the same password across multiple sites

70 _%

use a password as the primary way to login

Users often forget their passwords, which accounted for the majority of password-related inquiries. There were also inquiries from users who had forgotten their login IDs in addition to their passwords. At their peak, these inquiries accounted for more than a third of all account-related inquiries.

By going passwordless, Yahoo! JAPAN aimed to improve not only security, but also usability, without placing any extra burden on users.

From a security perspective, eliminating passwords from the user authentication process reduces the damage from list-based attacks, and from a usability perspective, providing an authentication method that does not rely on remembering passwords prevents situations where a user is unable to login because they forgot their password.

Yahoo! JAPAN's passwordless initiatives #

Yahoo! JAPAN is taking a number of steps to promote passwordless authentication, which can be broadly divided into three categories:

Provide an alternative means of authentication to passwords.
Password deactivation.
Passwordless account registration.

The first two initiatives aimed at existing users, while passwordless registration is aimed at new users.

1. Providing an alternative means of authentication to passwords #

Yahoo! JAPAN offers the following alternatives to passwords.

In addition, we also offer authentication methods such as e-mail authentication, password combined with SMS OTP (one time password), and password combined with email OTP.

SMS authentication #

SMS authentication is a system which allows a registered user to receive a six-digit authentication code through SMS. Once the user receives the SMS, they can enter the authentication code in the app or website.

Apple has long allowed iOS to read SMS messages and suggest authentication codes from the text body. Recently, it's become possible to use suggestions by specifying "one-time-code" in the autocomplete attribute of the input element. Chrome on Android, Windows, and Mac can provide the same experience using the WebOTP API.

For example:

<form>
  <input type="text" id="code" autocomplete="one-time-code"/>
  <button type="submit">sign in</button>
</form>

if ('OTPCredential' in window) {
  const input = document.getElementById('code');
  if (!input) return;
  const ac = new AbortController();
  const form = input.closest('form');
  if (form) {
    form.addEventListener('submit', e => {
      ac.abort();
    });
  }
  navigator.credentials.get({
    otp: { transport:['sms'] },
    signal: ac.signal
  }).then(otp => {
    input.value = otp.code;
  }).catch(err => {
    console.log(err);
  });
}

Both approaches are designed to prevent phishing by including the domain in the SMS body and providing suggestions only for the specified domain.

For more information about the WebOTP API and autocomplete="one-time-code", check out SMS OTP form best practices.

FIDO with WebAuthn #

FIDO with WebAuthn uses a hardware authenticator to generate a public key cipher pair and prove possession. When a smartphone is used as the authenticator, it can be combined with biometric authentication (such as fingerprint sensors or facial recognition) to perform one-step two-factor authentication. In this case, only the signature and the success indication from the biometric authentication are sent to the server, so there is no risk of biometric data theft.

The following diagram shows the server-client configuration for FIDO. The client authenticator authenticates the user with biometrics and signs the result using public key cryptography. The private key used to create the signature is securely stored in a TEE (Trusted Execution Environment) or similar location. A service provider that uses FIDO is called an RP (relying party).

Once the user performs the authentication (commonly with a biometric scan or PIN), the authenticator uses a private key to send a signed verification signal to the browser. The browser then shares that signal with the RP's website.

The RP website then sends the signed verification signal to the RP's server, which verifies the signature against the public key to complete the authentication.

For more information, read authentication guidelines from the FIDO Alliance.

Yahoo! JAPAN supports FIDO on Android (mobile app and web), iOS (mobile app and web), Windows (Edge, Chrome, Firefox), and macOS (Safari, Chrome). As a consumer service, FIDO can be used on almost any device, which makes it a good option for promoting passwordless authentication.

Operating System	Support for FIDO
Android	Apps, Browser (Chrome)
iOS	Apps (iOS14 or later), Browser (Safari 14 or later)
Windows	Browser (Edge, Chrome, Firefox)
Mac (Big Sur or later)	Browser (Safari, Chrome)

Sample Yahoo! JAPAN prompt to authenticate with FIDO.

Yahoo! JAPAN recommends that users register for FIDO with WebAuthn, if they've not already authenticated through other means. When a user needs to log in with the same device, they can quickly authenticate using a biometric sensor.

Users must set up FIDO authentication with all devices they use to log in to Yahoo! JAPAN.

To promote passwordless authentication and be considerate of users who are transitioning away from passwords, we provide multiple means of authentication. This means that different users can have different authentication method settings, and the authentication methods they can use may differ from browser to browser. We believe it's a better experience if users log in using the same authentication method each time.

To meet these requirements, it's necessary to track previous authentication methods and link this information to the client by storing it in the form of cookies, etc. We can then analyze how different browsers and applications are used for authentication. The user is asked to provide appropriate authentication based on the user's settings, the previous authentication methods used, and the minimum level of authentication required.

2. Password deactivation #

Yahoo! JAPAN asks users to set up an alternative authentication method and then disable their password so that it cannot be used. In addition to setting up alternative authentication, disabling password authentication (therefore making it impossible to sign in with only a password) helps protect users from list-based attacks.

We've taken the following steps to encourage users to disable their passwords.

Promoting alternative authentication methods when users reset their passwords.
Encouraging users to set up easy-to-use authentication methods (such as FIDO) and disable passwords for situations that require frequent authentication.
Urging users to disable their passwords before using high-risk services, such as e-commerce payments.

If a user forgets their password, they can run an account recovery. Previously this involved a password reset. Now, users can choose to set up a different authentication method, and we encourage them to do so.

3. Passwordless account registration #

New users can create password-free Yahoo! JAPAN accounts. Users are first required to register with an SMS authentication. Once they've logged in, we encourage the user to set up FIDO authentication.

Since FIDO is a per-device setting, it can be difficult to recover an account, should the device become inoperable. Therefore, we require users to keep their phone number registered, even after they've set up additional authentication.

Key challenges for passwordless authentication #

Passwords rely on human memory and are device-independent. On the other hand, the authentication methods introduced thus far in our passwordless initiative are device-dependent. This poses several challenges.

When multiple devices are used, there are some issues related to usability:

When using SMS authentication to log in from a PC, users must check their mobile phone for incoming SMS messages. This may be inconvenient, as it requires the user's phone to be available and easy to access at any time.
With FIDO, especially with platform authenticators, a user with multiple devices will be unable to authenticate on unregistered devices. Registration must be completed for each device they intend to use.

FIDO authentication is tied to specific devices, which requires they remain in the user's possession and active.

If the service contract is canceled, it will no longer be possible to send SMS messages to the registered phone number.
FIDO stores private keys on a specific device. If the device is lost, those keys are unusable.

Yahoo! JAPAN is taking various steps to address these problems.

The most important solution is to encourage users to set up multiple authentication methods. This provides alternative account access when devices are lost. Since FIDO keys are device-dependent, it is also good practice to register FIDO private keys on multiple devices.

Alternatively, users can use the WebOTP API to pass SMS verification codes from an Android phone to Chrome on a PC.

We believe that addressing these issues will become even more important as passwordless authentication spreads.

Promoting passwordless authentication #

Yahoo! JAPAN has been working on these passwordless initiatives since 2015. This began with the acquisition of FIDO server certification in May 2015, followed by the introduction of SMS authentication, a password deactivation feature, and FIDO support for each device.

Today, more than 30 million monthly active users have already disabled their passwords and are using non-password authentication methods. Yahoo! JAPAN's support for FIDO started with Chrome on Android, and now more than 10 million users have set up FIDO authentication.

As a result of Yahoo! JAPAN's initiatives, the percentage of inquiries involving forgotten login IDs or passwords has decreased by 25% compared to the period when the number of such inquiries was at its highest, and we have also been able to confirm that unauthorized access has declined as a result of the increase in the number of passwordless accounts.

Since FIDO is so easy to set up, it has a particularly high conversion rate. In fact, Yahoo! JAPAN has found that FIDO has a higher CVR than SMS authentication.

25 _%

Decrease in requests for forgotten credentials

74 _%

Users succeed with FIDO authentication

65 _%

Succeed with SMS verification

FIDO has a higher success rate than SMS authentication, and faster average and median authentication times. As for passwords, some groups have short authentication times, and we suspect that this is due to the browser's autocomplete="current-password".

On average, FIDO takes 8 seconds to authenticate, while passwords take 21 seconds, and SMS verification takes 27.

The greatest difficulty for offering passwordless accounts is not the addition of authentication methods, but popularizing the use of authenticators. If the experience of using a passwordless service is not user-friendly, the transition will not be easy.

We believe that to achieve improved security we must first improve usability, which will require unique innovations for each service.

Conclusion #

Password authentication is risky in terms of security, and it also poses challenges in terms of usability. Now that technologies supporting non-password authentication, such as WebOTP API and FIDO, are more widely available, it's time to start working toward passwordless authentication.

At Yahoo! JAPAN, taking this approach has had a definite effect on both usability and security. However, many users are still using passwords, so we will continue to encourage more users to switch to passwordless authentication methods. We will also continue improving our products to optimize the user experience for passwordless authentication methods.

Photo by olieman.eth on Unsplash