{"id":3142,"date":"2022-11-15T10:09:22","date_gmt":"2022-11-15T10:09:22","guid":{"rendered":"http:\/\/the-codest.localhost\/blog\/4-common-web-accessibility-issues-to-know\/"},"modified":"2026-03-09T13:10:53","modified_gmt":"2026-03-09T13:10:53","slug":"contrast-ratio-issue","status":"publish","type":"post","link":"https:\/\/thecodest.co\/en\/blog\/contrast-ratio-issue\/","title":{"rendered":"4 Common Web Accessibility Issues to Know"},"content":{"rendered":"\n

Contrast Ratio Issue<\/h2>\n\n\n\n

The most common accessibility issue I’ve seen over the years is the contrast and color accessibility issue<\/b>, a bad contrast ratio will make it hard to see the content of your page and that will be very harmful to your users, including those with visual disabilities. <\/p>\n\n\n\n

Contrast is a measure of the difference in perceived “luminance” or brightness between two colors, for example, it is the difference between the background color and foreground color of your page content. Let’s take a look at this navbar.<\/p>\n\n\n\n

\"navligational<em>bar<\/em>with<em>green<\/em>titles\"<\/figure>\n\n\n\n

Let’s say your client really likes that greenish color and finds it awesome, but there is an issue here with contrast. We have a #FFFFFF<\/code> background with a #83A94C<\/code> text color resulting in a 2.71:1 contrast ratio, which is way below the minimum 4.5:1<\/strong> needed. To detect this issue we have multiple solutions: <\/p>\n\n\n\n

    \n
  1. Use an online contrast checker like the Webaim Contrast Checker<\/a>, which will calculate the contrast ratio and give you a Pass<\/strong> or Fail<\/strong> grade.<\/li>\n\n\n\n
  2. Use one of the many browser contrast checker extensions, ex: WCAG Color contrast checker<\/a>.<\/li>\n\n\n\n
  3. Try out the browsers integrated contrast checker. To use it on Google Chrome, open the dev tools, inspect the targeted element (ex: Home link of our navbar), go to the CSS color property, and click on the color rectangle to open the color picker, at the bottom, you will be presented with a contrast ratio value, expand it for more details. The process is exactly the same for Firefox, just a small difference in the ratio is shown in the bottom left of the color picker.<\/li>\n<\/ol>\n\n\n\n
    \"black<em>background<\/em>with<em>blue<\/em>code<\/figure>\n\n\n\n

    To get more details about contrast check this Contrast and Color Accessibility Article<\/a>.<\/p>\n\n\n\n

    Link Text Issue<\/h2>\n\n\n\n

    Links are a big part of the web<\/a> these days, so making them accessible is very important. A link must make sense and inform the user of its context, so an uninformative link with text like read more, click here, check details isn’t very helpful so instead of adding “check details” for product<\/a> details, for example, using the product name such as “The Mandalorian Helmet” is better and more informative. Words like click here<\/code> or more about<\/code> can be omitted because a link is clickable per default and something like “more about today’s news” can be shortened to “today’s news”. There is no special rule or limit about link length, the link needs to be readable<\/b> and long enough to give a good description of its purpose.<\/p>\n\n\n\n

    Images as links are a widely used pattern, so this has to follow the same rules we’ve talked about above. The image alt attribute will play the role of link text and be announced by screen readers. There are multiple case scenarios when treating images as links, if the image is the only content of the link, then it must have an alt attribute, if the link has some text and image in it then we can omit the alt attribute, here are some examples:<\/p>\n\n\n\n

    \r<a href=\"\/notifications\">\r\n  <img src=\"\/img\/notification.png\" alt=\"Notifications\">\r\n<\/a><\/code><\/pre>\n\n\n\n
    Check out some links here to read about links accessibility:Link Text and Appearance<\/a>, Functional Images<\/a>.<\/p>\n\n\n\n
    Form Input Missing a Label<\/h2>\n\n\n\n
    \"input<em>labels<\/em>with<em>blue<\/em>button\"<\/figure>\n\n\n\n
    We’ve all seen these form inputs before with no label and just a placeholder to describe the purpose of the input. A first note is that as soon as the user fills in all the inputs and the placeholders aren’t in sight anymore we will have no visual context about the inputs purpose but let us<\/a> focus on the accessibility here. <\/p>\n\n\n\n
    Associating a label<\/code> to an input gives us two major advantages, a screen reader will read out the label when the user is focused on the form input and when a label is clicked or touched\/taped the browser passes the focus to its associated input. An easy fix for this kind of situation is to just add labels as follows:<\/p>\n\n\n\n
        First name\n\n    \n  \n\n    Last name\n\n    \n  \n\n    Email\n\n    \n  \n\n    Submit\n  \n\n```<\/code><\/pre>\n\n\n\n
    That’s it, all inputs have their associated labels making them accessible to everyone. We can even remove the placeholders to avoid duplicating the input purpose, but we all know that real-world scenarios aren’t so easy to deal with, you’ve just received a design that has these form inputs without labels and the client doesn’t want to change that part. The first solution that comes to mind is to apply a display: none;<\/code> or visibility: hidden;<\/code> to our labels, this will hide them but they are still there right? These properties hide elements not only on the screen, but also for screen reader users, so this will not solve our problem.<\/p>\n\n\n\n
    We can use the clip pattern<\/strong> to solve this. In that way, we will hide the content visually, yet provide the content to screen readers. We will create the following CSS sr-only<\/code> class and apply it on all of our labels:<\/p>\n\n\n\n
     .sr-only:not(:focus):not(:active) {\n   clip: rect(0 0 0 0);\n   clip-path: inset(50%);\n   height: 1px;\n   overflow: hidden;\n   position: absolute;\n   white-space: nowrap;\n   width: 1px;\n }\n<\/code><\/code><\/pre>\n\n\n\n
    This will hide our labels, make them available for screen readers and match our design. The :not(:focus):not(:active)<\/code> pseudo-class prevents focusable elements such as a<\/code>, button<\/code>, input<\/code> from being hidden when receiving focus.<\/p>\n\n\n\n
    No Focus Indicator<\/h2>\n\n\n\n
    Once upon a time I did this on my global CSS stylesheet:<\/p>\n\n\n\n
    * {\noutline: none; \/* horrible mistake *\/\n}<\/code><\/pre>\n\n\n\n
    Around 2020 I noticed black borders showing up on Google Chrome form inputs when focused or on the buttons when tabbed into – that was really weird as I didn’t understand it at the time, after some research I’ve found out that it is because of the outline CSS property so removing solved that ‘Problem’ for me.<\/p>\n\n\n\n
    At that time I had no idea what was the correct way to do it.  After doing some investigation about the whys and the hows of that new default I found out that outline is an element focus indicator and if removed an obvious focus styling must be provided, basically what I was doing is considered a bad practice. You can customize focus indicators as you see fit, but removing them completely from the website is a big accessibility issue. Customizing an element focus styling is fairly easy for example:<\/p>\n\n\n\n
     a:focus {\n   outline: 4px solid #ee7834;\n   outline-offset: 4px;\n }<\/code><\/code><\/pre>\n\n\n\n
    Accessibility Tools<\/h2>\n\n\n\n
    Checking all of the issues we’ve talked about can be a lot of work to do, especially knowing that there is a lot more stuff to cover about accessibility, so to help us deal with accessibility we have 2 great browser extensions.<\/p>\n\n\n\n
    WAVE Evaluation Tool<\/a> is a suite of evaluation tools that helps us make our web content more accessible. It is available in both Google Chrome and Firefox. <\/p>\n\n\n\n
    Let’s try it on a small web page containing a navbar and an input missing a label and see what it returns, after installing the extension, we just need to click on the extension icon to use it.<\/p>\n\n\n\n
    \"white<em>window<\/em>with<em>grey<\/em>sections\"<\/figure>\n\n\n\n
    The Summary tab shows 1 error (form element missing a label), 2 contrast errors and 1 alert (missing heading structure), as you can see the result is very clear and detailed. The Details tab will render a list of all the errors, alerts, and features. We can also interact directly on the page by clicking on those red rectangles to check the error description and type.<\/p>\n\n\n\n
    Axe DevTools<\/a> is a powerful and accurate accessibility toolkit. It is available in both Google Chrome and Firefox. After installing the extension, we will need to open the browser dev tools and go to the axe DevTools tab and click Scan all of my pages.<\/p>\n\n\n\n
    \"DevTools<em>window<\/em>with<em>black<\/em>grey_sections\"<\/figure>\n\n\n\n
    You can see Axe DevTools has reported the same issues with the WAVE Evaluation Tool which are contrast issues, form element missing a label, and missing heading element, it even gave us some best practices to follow.<\/p>\n\n\n\n
    An additional way to test for accessibility is to use a screen reader and test your website with it, there are many screen readers available, to name just a few:<\/p>\n\n\n\n