Forem: Verónica Ojeda

Firefox, let's focus, please!

Verónica Ojeda — Wed, 10 Feb 2021 15:04:37 +0000

I've decided to share this tiny ~~miny mee~~ issue that we had in the last project that I worked on, just in case someone is facing the same problem, so they don't have to ~~waste~~ spend their time too.

As you might already know, I care about accessibility a lot, but caring is not enough, you need to learn, and there's a lot to learn in this field. Thankfully I'm in a team where everyone is really involved with this topic as well, so we're all learning together. And what a lesson we've learnt here...

But first things first, what's the focus?

Focus determines where keyboard events go in the page at any given moment. (...) Focus refers to which control on the screen (an input item such as a field, checkbox, button, or link) currently receives input from the keyboard, and from the clipboard when you paste content. (Source: Web Fundamentals)

They say an image is worth a thousand words and I couldn't agree more so here is a GIF of Codegram's site being used with the keyboard (TAB key) and each focusable element receiving the focus clearly by the blue rectangle.

The mystery of the lost focus on Firefox

We were performing some accessibility plus cross browser testing to check that the site we were building was accessible by keyboard in Chrome, Firefox and Safari. So after we finished the testing, the results were:

✅ Chrome
✅ Safari
❌ Firefox

It was not possible to navigate using the keyboard on Firefox. Focusable elements like anchors weren't accesible by keyboard, they weren't receiving the focus as they should.

We didn't know what could be causing it... was it Tailwind's fault? Maybe Nuxt? Vue? What about PostCSS pollyfill? Because when something is failing, you need to blame someone so who was guilty here, right? But the problem was that it didn't make any sense at all to be anything of the above.

Sometimes, being a software developer is not that different from being a CSI detective. I decided to begin from the most basic site I could think of and then add different things™ to find out who/what was causing/responsible for the issue.

So I tried to navigate using the keyboard with the simplest site ever, just a plain html with a few anchor elements. And it still didn't work! Instead of each link, the whole body was being focused. 🤯

The typical thing to say is "It works on my machine.", but in my case it's usually the other way around: "It doesn't work on my machine.". I have that gift, I break things. So I asked some coworkers to try it as well and surprise: it was working just for one but not for the rest. 🤯

This was the clue that I needed to determine that it definitely was something related to Firefox and not to the code or the technologies we used.

So what did you do to make it work in everyone's machine?

Well, I did what I do best, research! 🔎 But this time just focusing on the browser and nothing else, not a single technology.

And finally... 🥁 I found The Solution™.

In the end, it seems to be an issue related to Firefox and Mac since Catalina OS:

Firefox used to take the value from the user settings in System Preferences > Keyboard > Shortcuts so just by checking the "Use keyboard navigation to move between controls" checkbox you could navigate using the keyboard. But that's not working anymore.

Thankfully it has a quite easy solution:

Go to about:config
Search for accessibility.tabfocus and check that it's set to type Boolean with value true
Remove it and select Number instead
Click on the add button and then enter the value 7

After changing that option in Firefox, I checked back first my super simple html file and it worked! 🎉

Then I checked on the site we were building and indeed it was working as well. 🥳 We finally had the triple check:

✅ Chrome
✅ Safari
✅ Firefox

Mystery solved. 🕵️‍♀️

Remember, never lose hope, neither the focus! Specially you, Firefox. 🦊

Cover photo by Stefan Cosma on Unsplash

Migrating from WebStorm to Visual Studio Code

Verónica Ojeda — Wed, 21 Oct 2020 12:58:00 +0000

My story with Visual Studio Code (aka VS Code and vscode) hasn't been the typical love story but more of a toxic relationship. We've broken up and got back together so many times I can't even tell. But after all this time and all the experience behind us, I think we're both more mature now and it's the perfect time for this relationship to finally work.

Jokes aside, it's a fact that when we get used to working with a specific tool, in the end we all tend to fall in love with it. And this is perfectly normal, you feel more productive and everything feels really easy to do. You can do the exact same thing with many different tools, but with your favourite one you just do it faster and better, it boosts your productivity.

So why the change, you might ask, right?

When I began to work as a developer, my IDE was Eclipse until one awesome day I discovered the JetBrains suite and it was love at first sight. Since then, I've been working mostly with IntelliJ for the backend stuff and WebStorm for the frontend.

I just used VS Code for personal projects mostly to try something new, both the IDE and the project itself. But every time I tried to use VS Code in my job, I ended up frustrated, but it was because I wasn't feeling productive. The truth is that I wasn't using the right setup for me.

At Codegram most of the team use VS Code, on twitter there are many people that I follow (and that I look up to) that use it too, so the real question is, why not? I had given several tries in the past, why not another one?

The migration setup

This is my setup to boost your productivity working with VS Code if you're used to working with WebStorm.

Plugins

I'm not going to explain how they work, since they have a really good description in their respective marketplace pages.

Git Lens and Git Graph

VS Code comes with no UI for git, but these two plugins are really helpful to fill some of the features.

Local History

I can't count how many times this has saved the day. With WebStorm or any JetBrains IDE you just right click on any file and go to Local History > Show History and a new windows pop ups with all the changes you've made, so if you want to back an hour ago, you can! Just a minor reminder with this plugin, add .history/ to .gitignore.

Todo Tree

With JetBrains there is always a TODO tab that lists all the TODOs in the project. This plugin is even better cause you can list the TODOs, the BUGs, etc. and it's customizable.

Terminal

You can open the terminal on VS Code with a shortcut, but in WebStorm there's always a tab for that. For once I got used to a button instead of a shortcut. This plugin does the trick by adding a toggle button to your interface.

Snippets for Code completion

With WebStorm you could create components with the UI, so you could add a new Vue component, or Angular component, with the base structure empty in the created file. There are several snippets for VS Code depending on the framework you work with. In my case, I work with Vue so I'm using Vue VS Code Snippets. I also have Vetur for Syntax-highlighting among other features to help coding with Vue.

Keyboard shortcuts

One of the things that made me go back to WebStorm in the past was the shortuts. There are some keyboard shortcuts that once you get used to them, you just can't change them. Well, you could, but you'd rather not. So what I did to make the migration process less painful was to keep the shortcuts that I use the most.

To make it more readable I'm going to use just CMD instead of CTRL/CMD since I work with a Macbook.

Duplicate line: In VS Code the setting is usually copy line up/down with SHIFT+OPTION+UP/DOWN but I prefer to use CMD+D to duplicate the current line/selection just like in WebStorm.

Delete line: From SHIFT+CMD+K to CMD+Del.

Toggle line comment: From CMD+/ to CMD+7. To be fair this one is exactly the same, but I had it modified in WebStorm as well. By default CMD+7 is the shortcut to go to your bookmark number 7 in JetBrains (you could bookmark lines), but I didn't use it so I find it more useful this way.

Navigation: Although we cannot navigate by clicking on methods/classes, there are a couple of shorcuts to go to the previous/next find match. Actually we had to override one of them when setting the new Delete line command. So in this case it would be 'Add Selection To Next Find Match' shortcut from CMD+D to CTRL+J and 'Add Selection To Previous Find Match' to CTRL+K. Why these shortcuts? Well, I used to work with Jira a lot and these were the commands to move through tickets in a search 🤷‍♀️. With these two combined with CMD+F to search in the file and CMD+SHIFT+F to search everywhere it does the trick more or less. It's not the same, it's not as fast, but it's all we have when working with with VS Code.

I must say that there is an IntelliJ IDEA keybinding plugin, but it has a huge bug in my opinion. You cannot open files with a shortcut! In the JetBrains suite you hit Double SHIFT to open a file, the equivalent in VS Code would be CMD+P. The problem is that Double SHIFT is not a possible command in VS Code, so since the plugin overrides the VS Code keymap, you end up without being able to open a file neither with Double SHIFT nor CMD+P.

My list of Pros and Cons

Although this is not a Foo vs Boo post, I always find these kind of comparing lists really useful (I love lists, I'm not going to hide it). This one is based 100% on my experience and my opinion.

WebStorm

✅ A lot of functionallity out of the box.

✅ Really easy-to-use git UI.

✅ Code completion (i.e. to import a component you just use it in the HTML and it automatically imports it on the script).

✅ Navigation. Jump to a method, function or variable definition in just one click.

⚠️ Collaborative development. People have been asking for this feature for a while (16 years to be more precise), there were some third party plugins but none of them worked as they should, and finally they have released their own plugin Code With Me (although it's still on Early Access Program).

❌ Wants all the RAM and battery all to itself and I already use Chrome, so there's no more room for another RAM eater.

❌ Private and paid.

❌ Although it has a community, every time I had a problem it wasn't easy to find a solution.

What I miss the most about WebStorm

Git UI and Navigation features. 😭

The first one wasn't doing me any good really, cause I was so used to JetBrains UI for Git that it made me dependant on it. It boosted my productivity, and I find features like Project Update (CTRL/CMD+T) really helpful. This would do git fetch && git pull just with a keyboard shortcut. But in the end you forget what's really going on and that can be dangerous.

Opening files with Double SHIFT. It might sound silly, but once you get used to the double shift everything else feels like it's taking too much time. I still hit Double SHIFT a lot of times before going with the CMD+P 😂. There is an issue open, hopefully they will pay attention to it some day! (which probably would happen once I'm used to the CMD+P command)

But the hardest feature to give up is definetly jumping to a method, function or variable definition in just one click.

VS Code

✅ Free and Open Source.

✅ Fully Customizable.

✅ Great community.

✅ Really fast, it takes less than one second to open.

✅ Shares RAM and battery with the rest of my computer.

✅ Collaborative development with Live Share to do some pair programming.

✅ Format just the modified lines.

❌ Lack of some out of the box functionallity.

❌ Code completion.

❌ Navigation.

What I like the most about VS Code

The fact that I can work without burning my fingers cause the CPU is using all the resources available 🔥and also that I can work without being plugged in all the time cause my laptop runs out of battery. 🔋

I never did pair programming before, and I have done it just a couple of times so far but it's a really nice feature to have. And especially helpful when you work remotely, so now that most people are working remotely due to COVID I think it's essential.

Even though I had it in the cons list as "lack of features out of the box", since it comes with no Git UI, I'm finding it really good for me, cause now thanks to the plugins I have all the visual support that I need but also I have control over git again through the command line. Just as I said above, I think that it can be dangerous to rely 100% on a GUI for git.

Finally, there's a tiny miny feature on VS Code that means the world to me. When it comes to formatting code, IntelliJ IDEA has so many configurable options in the .editor file, with VS Code you can just set a few of them in that file. That's why I used to think JetBrains did it better, cause it allowed you to set more options. There are other formatting options like formatting code based on ESLint or Prettier, the most used one. But in the end is usually a pain in the ass, people work with different IDEs, different formatting options and in my experience the result usually is a mess. When you do a Pull Request there are 100 changes and 99 are because of the formatting. Setting the "Editor: Format On Save Mode" to "modifications" has saved my life. With that set, it only formats the lines you modify! 👏🏻 How cool is that, right?!

If I'm being honest, this is the main reason why I decided to give VS Code another chance and this feature along with everything explained above is what made me stay.

Final thoughts

I'm not saying that switching tools is better than sticking to one or viceversa.

If you feel comfortable with a tool and don't feel like changing it, it's fine. If you want to give new tools a try, that's fine as well. You might fall in love, either with the new tool or with your previous tool all over again.

Am I going to stick to VS Code? Who knows 🤔 It will depend on my needs and how they keep evolving.

What about you? Which IDE or Text Editor is your favourite to code and why? Have you ever tried to migrate to another one? Tell us on twitter!

Cover photo by Barth Bailey on Unsplash

But Lighthouse says I'm accessible! · Part 2

Verónica Ojeda — Fri, 25 Sep 2020 11:26:22 +0000

In the previous post we saw how to score 100 in accessibility in Lighthouse but still not having an accessible site. It's quite common to leave the a11y check for the end of the project, run some automatic tools, fix almost all the bugs they report and that's it.

But at this point you should know that's not enough, not even close to enough.

So... what can we do to improve accessibility? 🤔

Instead of developing a web and then checking for the accessibility, what if we try to be a little bit more empathetic with everyone and change the way we design and develop to take all of this into account from the very beginning?

And by everyone I mean EVERYONE, from the Client, to the Project Manager, the Designer, the Developers, the QA team, your friends, your family.

✅ Test before, during and after

Test as much as you can, run the automatic tools, take into account the manual checks and have a QA team if possible.

Wait, so even though we built the site thinking of accessibility, we need to test it as well?

Of course! We're not perfect, there will always be bugs, even if you don't intend to, and with a11y it's the same.

Usually we design, develop and test a site as usual, and in the end someone says "hey, maybe we should check the accessibility". What happens? There are a lot of a11y issues, and since it's at the end of the project, they're harder, and more expensive to fix, so not all of them will be fixed.

If we build a site thinking of a11y, and we test it all along, we'll be fixing the bugs during the design and development process, which is cheaper and faster. Although there might be some a11y bugs in the final check, there won't be a million!

For instance, now I'm using Vue, so it's component based, what we're doing is checking the a11y for each component, it makes it way easier.

✅ Go beyond the "100 Accessibility"

If we pay more attention to both Lighthouse and achecker, we'll notice they both provide more information about the accessibility.

In Lighthouse there's a list of items that should be manually checked. Although they don't mention anything about any of the accessibility bugs that I've listed above, they have a more detailed tutorial on how to perform these checks in the link they provide.

Something similar happens in achecker. Sure, by default they say "Congratulations! No known problems" but there are more tabs! If we go to the "Potential Problems (39)" tab we'll see that the very first potential issue they're talking about is one of our a11y bugs, the non-descriptive alt in the image:

And there are other tools where we wouldn't have passed the automatic tests for the a11y, like the axe extension for Chrome, which is the one that we use at Codegram:

✅ And go beyond WGAG too

This is a quote from the book that I'm currently reading:

"people with dyslexia have a particular problem with reading justified aligned texts. It’s not clear where a line of text ends which makes it very easy to switch to the wrong line." — Better Web Typography for a Better Web, Matej Latin

If we resize the screen a little bit, you'll see we're failing on that too in our sample (this is because of the CSS property we've set for the body text-align: justify;), and this time neither automatic tools nor WGAG have told us anything!

What I'm trying to say is that there are so many things to take into account, but do not feel overwhelmed. This is just like any other topic in this profession, that you might feel like there's a lot to learn, so just like you would do with any new cutting edge technology, learn about this.

Read, care and learn as much as you can, you will make mistakes, so will I, but we really need to care more about everyone. There are a lot of resources out there, now it's easier than ever to be an a11y superstar!

Plus, unlike the latest frontend framework, this is a safe bet, this won't be out of fashion ever!

✅ Follow people with special needs

I've always been aware of a11y, and then I cared even more after that month that I had to become an "expert", because during that time I realized how many accessibility issues needed to be taken into account and they aren't most of the time.

But what really helps me keep up with this topic is following people like Juanjo and Julian, blind software developers, who have to suffer all the non-accessible sites and apps.

Sometimes that's been more helpful than a thousand checklists and books.

✅ Last, but not least, A level is not an option

Try always to aim AA level at least (and remember there's more beyond WGAG!).

It will depend on the site, of course. It is not the same for a portfolio page than an official government site that every citizen will need to use eventually for some admin stuff.

You'd be surprised how many sites that should be accessible, aren't: from the famous Renfe web (the old one and the new one) to the new Radar COVID app, among many others like McDonald's and even Guardia Civil.

A final quote ✍️

Quoting w3.org for the third time (because there's always a third!), let's never forget this:

Web accessibility also benefits people without disabilities, for example:

People using mobile phones, smart watches, smart TVs, and other devices with small screens, different input modes, etc.

Older people with changing abilities due to ageing

People with “temporary disabilities” such as a broken arm or lost glasses

People with “situational limitations” such as in bright sunlight or in an environment where they cannot listen to audio

People using a slow Internet connection, or who have limited or expensive bandwidth

As the www stands for (World Wide Web), we do live in a wide world with many different people who have many different needs. And again it is not my intention to scare you, it's just a fact that none of us is free from having a temporary or permanent need in the future, so let's try to make a more accessible web (and world) together, from people to people 💪🏻.

Just remember... "I'll be there for you, because you will be there for me too 🎵".

#FunFact 👻

I know what you're thinking, for real this time, I'm not talking about the form... "When is she going to talk about Comic Sans? Why the hell has she used that font?" Well, I just wanted to attract your ~~hate~~ attention.

I'm kidding, I just needed an excuse to tell you that Comic Sans is an accessible typeface!! Did you know that? If you don't believe me, you can read this article "The Reason Comic Sans Is a Public Good" and this other one "Designing for accessibility: The best defense for Comic Sans".

Resources 🌐

Here are some tools and interesting links (most of them I've already mentioned), and don't worry, this won't be my last post about this topic.

Tools to check the accessibility:
- Lighthouse
- Axe (official page, chrome extension)
- Manual Contrast Checker (official page, chrome extension)
- Automatic Contrast Checker extension
Learn more about accessibility:
Another interesting links:
- Dos and don'ts on designing for accessibility

Cover photo by J. Kelly Brito on Unsplash

But Lighthouse says I'm accessible! · Part 1

Verónica Ojeda — Mon, 21 Sep 2020 11:37:03 +0000

Once upon a time I was a Quality Assurance Engineer and we had a project that needed to pass WCAG AA level in accessibility. But none of us had done accessibility testing before so they gave me one month to become an "expert" in accessibility. Guess what? I didn't become an expert, but I did learn a lot about it and how the automatic tools are super useful but still not enough.

Now I'm on the other side of the coin, I'm a developer, and developers tend to check the accessibility with automatic tools only (if it's checked at all).

Today I'm going to show you how we can pass all the automatic checks for accessibility but still not having an accessible site (and how to fix it, of course!).

Quick intro 👋🏻

What is accessibility (or a11y)?

Since there are so many definitions on the web, I'm going to quote one of my favorites from w3.org:

Web accessibility means that websites, tools, and technologies are designed and developed so that people with disabilities can use them. More specifically, people can:

Perceive, understand, navigate, and interact with the Web

Contribute to the Web

Web accessibility encompasses all disabilities that affect access to the Web, including:

Auditory

Cognitive

Neurological

Physical

Speech

Visual

WCAG Levels

I'm going to do it again, and quote the same web (sorry):

Web Content Accessibility Guidelines (WCAG) explains how to make web content more accessible to people with disabilities. WCAG covers web sites, applications, and other digital content. It is developed by the World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI). WCAG is an international standard.

There are three levels of conformance:

Level A is the minimum level.

Level AA includes all Level A and AA requirements. Many organizations strive to meet Level AA.

Level AAA includes all Level A, AA, and AAA requirements.

It's building time! 👷‍♀️

Enough quoting, let's get our hands dirty!

I hope you don't mind, but I've asked some Friends to help me build my cheeky and falsy accessible site, it's quite ugly I know, but it's still useful for the purpose of this post.

<!DOCTYPE html>
<html lang="es">
   <head>
      <meta charset="utf-8" />
      <link
         rel="stylesheet"
         href="https://stackpath.bootstrapcdn.com/bootstrap/4.5.2/css/bootstrap.min.css"
         integrity="sha384-JcKb8q3iqJ61gNV9KGb8thSsNjpSL0n8PARn9HuZOnIxN0hoP+VmmDGMN5t9UJ0Z"
         crossorigin="anonymous"
         />
      <title>Friends</title>
      <style>
         body {
            font-family: 'Comic Sans MS';
            text-align: justify;
         }
         .form-control {
            border-color: inherit;
         }
         .form-control:focus {
            border-color: inherit;
            -webkit-box-shadow: none;
            box-shadow: none;
         }
      </style>
   </head>
   <body>
      <div class="jumbotron jumbotron-fluid">
         <div class="container">
            <h1 class="display-4">
               Let's talk about <strong>F<span class="text-danger">·</span>R<span class="text-warning">·</span>I<span class="text-primary">·</span>E<span class="text-danger">·</span>N<span class="text-warning">·</span>D<span class="text-primary">·</span>S</strong>
            </h1>
            <p class="lead">
               Because of reasons.
            </p>
         </div>
      </div>
      <div class="container" style="padding-bottom: 32px;">
         <div class="row">
            <div class="col-lg-6">
               <h2>Meet the team 👋</h2>
               <p>As you can see in the picture below, these are the people that are going to help us building the webpage, do you like their names?</p>
               <img
                  class="img img-thumbnail rounded"
                  src="https://usercontent1.hubstatic.com/12527974.jpg"
                  alt="friends"
                  title=""
                  />
            </div>
            <div class="col-lg-6">
               <h3>Did you hear that? 👂</h3>
               <p>You need to pay attention to the lyrics!</p>
               <iframe title="song" src="https://open.spotify.com/embed/track/15tHagkk8z306XkyOHqiip" width="300" height="380" frameborder="0" allowtransparency="true" allow="encrypted-media"></iframe>
            </div>
         </div>
         <div class="row" style="padding-top: 32px;">
            <p>Do you wanna develop an app? Puh rum pum pow! I'm the Devil, what should I do when I fail? Give myself an ice cream? Hmmm, human music.</p>

            <p>Flip the pickle over. You little monster! I thought you were masturbating! Must… continue… moving… in… ways… that… lead… to… dying… with… you. You can run, but you can't hide bitch!</p>

            <p>Nice one, Ms Pancakes. What, cover me in gasoline and spiders? Fine, yeah, I'm in. Uh ohhh! Somersault jump! Aw, c'mon Rick. That doesn't seem so bad.</p>

            <p>This aftershave made women want me, but it also made me impotent! Listen, Morty, I hate to break it to you but what people call "love" is just a chemical reaction that compels animals to breed. It hits hard, Morty, then it slowly fades, leaving you stranded in a failing marriage. I did it. Your parents are gonna do it. Break the cycle, Morty. Rise above. Focus on science. It probably has space aids. Must… continue… moving… in… ways… that… lead… to… dying… with… you.</p>
         </div>
         <div class="row" style="padding-top: 32px;">
            <div class="col-lg-12">
               <h4>If you like this page, please fill in the following form which will literally do nothing 😅</h4>
               <form>
                  <div class="form-row">
                     <div class="col-7">
                        <label for="city" class="sr-only">City</label>
                        <input id="city" type="text" class="form-control" placeholder="nothing">
                     </div>
                     <div class="col">
                        <label for="state" class="sr-only">State</label>
                        <input id="state" type="text" class="form-control" placeholder="I">
                     </div>
                     <div class="col">
                        <label for="zip" class="sr-only">Zip</label>
                        <input id="zip" type="text" class="form-control" placeholder="do">
                     </div>
                  </div>
                  <div class="form-row" style="padding-top: 16px;">
                     <div class="col-12">
                        <button onclick="alert('I told you I did nothing!')" type="submit" class="btn btn-dark">Submit</button>
                     </div>
                  </div>
               </form>
            </div>
         </div>
         <div class="row" style="padding-top: 32px;">
            <div class="col-lg-12">
               <h3>And last, but not least... learn some French with Joey 🇫🇷</h3>
               <iframe
                  title="episode fragment"
                  width="560"
                  height="315"
                  src="https://www.youtube.com/embed/DqwzvtjeYBQ"
                  frameborder="0"
                  allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture"
                  allowfullscreen
                  ></iframe>
            </div>
         </div>
      </div
         >
      </div>
   </body>
</html>

I know exactly what you're thinking. What an ugly form, right?

It's play time! 🎮

Now that we have our super beautiful and accessible site, let's run some automatic tools to check if we've accomplished the accessibility requirements.

But first, we need to serve it locally in order to run those tools. So let's use http-server which is quite simple, just go to your project's folder where your index.html file is and run:

npx http-server

We're ready to go, let's run Lighthouse to make sure it it's accessible indeed:

Go to http://localhost:8080
Open the DevTools and go to the Lighthouse tab
Make sure the 'accessibility' checkbox is ticked and click on 'Generate report' (actually it's even better if you uncheck the rest of them so it is way faster)

Yay! we did it! 🥳 Wait... but, did we? 🤔

But Lighthouse says I am accessible! 😢

And not only Lighthouse, if we take our site and try to run other automatic tools that check the accessibility, we would find out that the results are quite similar.

Let's double check in achecker where you upload a file:

You can try to play a game and go back to our html file and try to spot as many accessibility bugs as you can in 1 minute (I'm like Monica in Friends when it comes to create fun games at parties, I know right?).

Or you can cheat and just keep reading because I'm going to list them below.

1.1.1 Non-text Content - Level A

We have a non-decorative image that even though it has an alt description, it is not descriptive enough.

<img
    class="img img-thumbnail rounded"
    src="https://usercontent1.hubstatic.com/12527974.jpg"
    alt="friends"
    title=""
    />

Just the paragraph above is asking the users what they think about the character names, and they are only displayed in the picture. This can be solved either by adding the names to the paragraph per se or by adding them to the alt description, e.g:

<img
    class="img img-thumbnail rounded"
    src="https://usercontent1.hubstatic.com/12527974.jpg"
    alt="Picture of all the Friends characters divided in two rows and three colums, and the rows are separated by the 'FRIENDS' title. Each character is holding their name in a sign. In the first row from left to right we have Ross, Joey and Monica, in the second row Chandler, Rachel and Phoebe."
    title=""
    />

1.2.1 Audio-only and Video-only (Prerecorded) - Level A

We have a video that promise us to learn French with Joey and that's the only way to learn French in our page. We haven't given any alternative resources for that video, like a transcript, or another video with captions.

Something similar happens with the audio for the Friends theme song. We should have added the lyrics in plain text or at least a link with the lyrics

In both cases, people with hearing impairment wouldn't be able to use our whole content of the page.

2.4.2 Page Titled - Level A

Okay we do have a title, we've set <title>Friends</title>, but the purpose of the page title is to say where we are.

Where are we? In the Home page? In the Contacts page? "Friends" talks about the content which is good but "Home - Friends" would have been even better.

2.4.7 Focus Visible - Level AA

If you try to use the keyboard to navigate through the page, you'll see that it isn't easy to tell if we're in the form or anywhere else on the page. If it's difficult for people without problem visions, it's impossible for people who suffer them.

It's because of this part of the CSS. We should remove it.

.form-control {
    border-color: inherit;
 }
 .form-control:focus {
    border-color: inherit;
    -webkit-box-shadow: none;
    box-shadow: none;
 }

3.1.1 Language of Page - Level A

We're bad people, we've set <html lang="es"> but the page is in English.

Blind people or people with several vision problems, use assistive technology to navigate through the page.

This technology reads the content depending on the language we set, so if we don't specify the language of the page, or the different sections in case we have sections in different languages (3.1.2 Language of Parts - Level AA) then it's impossible for them to understand a word.

Is that all? 🤔

No way! I've only picked a tiny miny of a way longer list of all the accessibility items that need to and can only be checked manually. If you want to see them all, checkout these checklists in the a11y project.

In the next post, we'll see a few more improvements to the sample site we've built here and what can we do to improve the accessibility in all the projects we work on. 💪🏻

Cover photo by Yomex Owo on Unsplash