There are several guidelines that needs to be followed for making web content accessible & the most popular is Web Content Accessibility Guidelines 2.1 (WCAG). For a new front-end developer, it could be overwhelming to understand WCAG. Since it has 4 principles, 13 guidelines, 78 success criteria’s & each success criteria have multiple techniques and failures.  

So, if you are a React developer who wants to start building accessible websites, today I will cover how you can find accessibility issues when you write the code and fix it very easily, so you ship accessible code! 

Eslint-plugin-jsx-a11y 

Eslint-plugin-jsx-a11y is a plugin which performs a static evaluation of the JSX code to find accessibility issues in React websites. It also provides errors & hints to fix them. It has total 36 different rulesets & few of them can be more customized when used with “recommended” mode. 

Note: For the following steps you will need a code editor like Visual studio Code. 

Step 1: Let’s create a demo react-app 

Create a demo react app using following command.  

npx create-react-app my-app

Now write some code of your application in App.jsx file which is inaccessible. For instance, we have created navigation links & a sign up form. 

<div className="App"> 
      <div className="app-header">
      <img src="/image/logo.png" className="App-logo" /> 
          <div class="primar-nav"> 
              <a href="/home">Home</a> 
              <a href="/services">Our services</a> 
              <a href="/signup" tabIndex="1">Sign Up</a> 
          </div> 
      </div> 
      <div className="app-content"> 
        <div>Sign up</div> 
          <p>Enter your details below to sign up!!</p>
        <label>First name</label> 
        <input type="text" id="fname" /> 
        <label>Last name</label> 
        <input type="text" id="lname"/> 
        <label>Email</label> 
        <input type="text" id="email"/> 
        <label>Password</label> 
        <input type="password" id="password"/> 
        <div 
          onClick={() => {   
            user_signUp(); 
          }} 
        > 
          Sign Up 
        </div> 
      </div> 
    </div> 

Step 2: Now, let’s Install es-lint package 

To install es-lint package, run the following command in terminal. 

npm install eslint --save-dev

Step 3: Now, Install eslint-plugin-jsx-a11y package. 

To install the eslint-plugin-jsx-a11y package, run the following command in terminal.  

npm install eslint-plugin-jsx-a11y --save-dev

Step 4: Now let’s setup .eslintrc.json & Package.json files 

Create a file with name “.eslintrc.json” in your src folder & write the following code inside the file. It will act as a configuration file for our eslint package. 

{"extends": ["plugin:jsx-a11y/strict"]}

Add the following code inside Package.json file inside “scripts” object. 

"lint": "eslint src"

Step 5: Now let’s fire up the engines & take this for a test drive!!  

In the terminal run the command: npm run lint

You will see terminal throws the following accessibility errors along with line number of code where the error is found. 

• img elements must have an alt prop, either with meaningful text, or an empty string for decorative images 
• Avoid positive integer values for tabIndex. 
• A form label must be associated with a control.    
• Visible, non-interactive elements with click handlers must have at least one keyboard listener.  
• Avoid non-native interactive elements. If using native HTML is not possible, add an appropriate role and support for tabbing, mouse, keyboard, and touch inputs to an interactive content element. 

As a developer, you might be wondering what does each error mean and how should you fix them? No worries! We got you covered! 

How to understand issues & fix them? 

1. img elements must have an alt prop, either with meaningful text, or an empty string for decorative images 

   Images without alternate text are difficult to perceive for screen reader users. They won’t know if the image exists if alternate text is not given. To fix this issue provide alt attribute to the img element with descriptive alternate text as shown below:

   <img src="images/logo.png" className="App-logo" alt="Company logo" />
   
   

   Check out Images tutorial from W3C to learn more about accessible Images.

2. Avoid positive integer values for tabIndex

   When positive tabindex values are used it creates an unexpected tab order, which makes tabbing order less intuitive for keyboard-only users. In our website when user will navigate through the page with tab key the focus will be set to “Sign Up” link first instead of “Home” link which is appearing first visually. This will disorient keyboard, low vision & screen reader users while accessing the page contents. To fix this issue remove tabindex attribute from anchor element as shown below: 

   <a href="/signup">Sign Up</a>

   Check out tabindex attribute from MDN Web Docs to learn more.  

3. A form label must be associated with a control 

   The <label> element must be associated with the respective input control pragmatically. This will ensure that the assistive technology users understand the purpose of input fields. The id & htmlFor attributes can be used to associate the input control with a label. To fix this issue associate the labels with respective input controls as shown below: 

     
   <label htmlfor="fname">First name</label>
   <input type="text" id="fname" />
   
   <label htmlfor="lname">Last name</label>
   <input type=”text” id=”lname” /> 
   
   <label htmlfor="email">Email</label>
   <input type="text" id="email" /> 
   
   <label htmlfor="password">Password</label>
   <input type="text" id="password" /> 
   

   Check out Labelling Controls from W3C to learn more. 

4. Visible, non-interactive elements with click handlers must have at least one keyboard listener.  

   When a non-interactive element such as <div>, <span> & so on are used for interaction which have only click events, they won’t be operable with a keyboard. This will make it difficult for screen reader & keyboard-only users to activate the element. To activate a Button, Enter/Return  or Spacebar keys are used. So, in case of non-interactive element, you need to add a script to listen to these key events. To fix this issue add a keyboard event equivalent to click event as shown below: 

    
   <div       
         onClick={() => {
            user_signup();
          }}
          onKeyDown={(event) => {
          if (event.which === 13 || event.which == 32) {
            user_signUp();
          }
          }}
         >  
        Sign Up 
   </div>  
   

5. Avoid non-native interactive elements. If using native HTML is not possible, add an appropriate role and support for tabbing, mouse, keyboard, and touch inputs to an interactive element. 

   Non-native elements such as <div>, <span>; and so on do not have any semantic meaning & hence when they are used for interactions on the page it becomes difficult for assistive technology users to understand their purpose. Instead, native interactive HTML elements such as anchor(<a>), button(<button>), form controls like radio button (<input type="radio">) & checkbox (<input type="checkbox">) and so on should be used. 

   If using native HTML elements is not possible then you should provide appropriate roles, states & properties of ARIA along with keyboard support for the non-native elements. To fix this issue provide role="button” & tabindex="0” attributes to the <div> element as shown below: 

   
   <div 
        onClick={() => {   
        user_signup(); 
        }} 
        onKeyDown={(event) => { 
        if (event.which === 13 || event.which == 32) { 
          user_signUp(); 
        } 
        }} 
        role=”button” 
        tabindex=”0” 
        > 
        Sign Up 
   </div> 
   
   

Fixed all the errors? Let’s test again! 

After fixing all the errors if you run the command npm run lint again you won’t get any errors in terminal & your application will be compiled successfully! 

Plugin Modes 

This plugin comes with 2 modes. 

1. Strict – Enabled by default & offers more rules set by default. 
2. Recommended – It has less rules enabled by default. Allows some rules to have extra options in this mode. 
   

You can also create & configure your own custom rules as per the requirements. 

You can read more details about the plugin & other rules in the eslint-plugin-jsx-a11y github page. 

Wait, this is not the end!! 

There are more issues in our code which were not captured by the plugin. Yes that’s true, automated testing can’t identify all the Accessibility errors. So, we will perform a basic manual test to identify the remaining issues. Manual testing is a must when it comes to Accessibility of digital solutions! 

1. The links such as “Home”, “our services“, “Sign up” and so on visually look like a list but not marked as list programmatically. Also, these links should be wrapped inside <nav> element along with a unique label which would render as a Navigation landmark for screen reader users. CSS can be used to maintain the presentation of the page. 
    
   To fix this issue wrap the links inside an unordered list <ul> & <nav> element. Also provide aria-current="page" attribute to the link which represents the current page within set of navigation links. 
    
   

    <nav aria-label="primary"> 
     <ul> 
       <li><a href="/home">Home</a></li> 
       <li><a href="/services">Our Services</a></li> 
       <li><a href="/signup" aria-current="page"> Sign Up</a></li> 
     </ul> 
   </nav>  

2. The text “Sign Up” inside the main content visually constitutes as a section heading but is not marked as heading programmatically. 
    
   To fix this issue mark the text “Sign Up” as heading with <h1> element. 
    
   <h1>Sign Up</h1> 

Hence manual testing needs to be performed with keyboard, screen reader & other assistive technologies to find issues which needs human judgment. We also recommend including people with disabilities in your testing process to get overall feedback about their experience. 

There are more automated tools like ANDI, WAVE and so on which can be used to find more accessibility issues on the rendered output. 

Note that these were simple elements & accessibility can be implemented even for complex interactions like search, drag & drop and so on. 

Accessibility in React official documentation also has more detailed information on how you can implement accessibility in React based websites. 

To summarize,  

1. We wrote code that was not accessible. 
2. Setup the eslint-plugin-jsx-a11y plugin. 
3. Ran the test & got the a11y errors inside terminal. 
4. Understood about the errors & how to solve them. 
5. Fixed our code & compiled successfully.  
6. Congratulations!! You successfully shipped accessible code because coding for accessibility isn’t difficult! 

Looking for a reliable digital accessibility partner that can help you help you think accessibility first and build accessibility features into your digital products? Write to us at sales@barrierbreak.com or schedule a consultation with our accessibility expert.

This article by Siddharaj Suryavanshi is a part of our BB Geek series where BarrierBreak team members share their expertise on accessibility and inclusion, drawing from their extensive experience in the field.

The post Code for everyone – Find & Fix Accessibility Issues in React appeared first on Leader in Offshore Accessibility Testing | Section 508 Compliance | WCAG Conformance | BarrierBreak.

Label is an important piece of text that tells you what the purpose of the control is. Users can decide based on the label if clicking or activating the button will submit the form details or reset the form! 

Unique and descriptive labels must be provided for all types of controls.  

Adding visual labels is beneficial for all users but it is essential to remember to programmatically define the labels. A programmatically defined label will tell assistive technology users about the purpose of the control when they navigate between different controls on a web page or an application. In the absence of label, assistive technology will identify the control as unlabeled! Furthermore, off-screen labels should be avoided as they are not available for everyone! 

Labels can be provided in the form of text, images, symbols, text along with images or symbols. In the case of images used as labels, make sure that textual descriptions are added such that the information can be made available for assistive technology users! 

Generally, textual labels are provided for input fields, drop-downs, checkboxes, and radio buttons whereas symbols or icons are used for menus and buttons. It is recommended to place labels to the left or top of input fields and drop-downs and on the right of checkboxes and radio buttons.  

For Global Accessibility Awareness Day, (GAAD 2023), BarrierBreak ran a campaign “#LabelYourControls” as we believe Accessibility is a journey and labelling your controls is a crucial step of this journey when it comes to making your digital solutions accessible for people with disabilities! Our team shared helpful tips throughout the day i.e. 18th May, 2023 marking GAAD on Twitter, LinkedIn and Facebook.

Download the 12 tips on how to #LabelYourControls on web, android and iOS and feel free to share these tips with your colleagues, friends, or anyone who may be interested in promoting accessibility. 

Download Now

The post Importance of Labelling your Controls  appeared first on Leader in Offshore Accessibility Testing | Section 508 Compliance | WCAG Conformance | BarrierBreak.

Most of the time everyone wants fancy products, but they forget while making them fancy they are not considering accessibility. Accessibility is not just for people with disabilities, it will always benefit every user!

With so many questions, there also comes the “misconceptions” about the accessibility for the interactive elements. In this blog we will try to bust such myths or the so-called misconception by separating the facts from fiction! So, fasten your seat belt (don’t worry I am not taking you for a ride!) and let’s bust them together!

Myth 1: Making interactive elements accessible is time-consuming and expensive

Fact: Most accessibility fixes are relatively simple and inexpensive to implement if you stick to basics i.e., using native HTML elements over custom interactive elements. Moreover, integrating it into the design process itself takes care of lot of foreseeable accessibility issues that occurs during the development phase. But if you keep on waiting for the magic to happen on its own – then you will definitely be late to the party for fixing – which will take a lot of planning to tackle the issues that will occur

Myth 2: The accessible interactive elements are visually boring

Fact: It’s not hidden that everyone want some fancy intuitive websites that are visually appealing! But the beauty about accessibility is you don’t have to compromise on the visual look and feel. You just have to ensure that keeping accessibility in mind you are choosing the right color, the right font size and keeping it user friendly as well. Accessible design can not only be visually appealing but it can actually enhance the user experience for all users, not just those with disabilities. You can use our friend “CSS” to achieve the look and feel that you desire even on the native HTML elements!

Myth 3: Assistive technologies will take care of accessibility of interactive elements, developers need not worry about it

Fact: It’s like saying all the vehicles will drive themselves, driver need not have to worry! Lol

Note: Yes, I know that’s possible in some vehicles now! But you get the point, right?

While assistive technologies can help people with disabilities to access the content, they DO NOT guarantee accessibility. Whatever the assistive technology picks it picks up from the underlying code behind the elements. It’s not like Aladdin’s magical lamp, that you rub it and things come true! Developers, Designers and Content Writers need to make sure the content is designed, written and coded keeping accessibility in mind.

For example, a button needs to be identified with a role of button because the screen reader can’t dream of it to be a button! So, if you code a button as <button>Hit me</button>, the assistive technology like screen reader will identify it as “Hit me, button.”

If you design a button that has very poor contrast, someone with low vision or color blindness won’t be able to perceive the button clearly. 

Similarly, if you are designing an accordion which show/hide the content, wherein though visually the content is available but you forget to remove aria-hidden attribute when content is visible or forget to change the value to “false”, then you are asking for trouble! A screen reader will not be able to access that content if aria-hidden is still present with a value of “true”. 

Myth 4: Scripted interactive elements can be accessed by all

Fact: Imaging if I tie your hands at the back and ask to pick up a glass that is on the top shelf – will you be able to? No, right? You will require help here!

Then why assume everyone will use a mouse to interact with an element? When a scripted element is present on the website that’s functional only using a mouse – it’s a BLOCKER for people with motor disability who might just use a keyboard/switch devices to interact with the website. Even in certain situational disability like when your mouse dies and the only way to hit that button to book your last available seats of your favourite Marvel/DC movie is with a keyboard – but meh! You cannot reach it or activate it! The tickets are now sold out Wouldn’t this be frustrating? It’s the same with scripted elements. So, next time If you code an interactive element, ensure that it’s reachable and actionable using different input devices.

Myth 5: Providing tabindex=”0” will magically make the custom interactive element actionable!

Fact: This is one of my favorites. I have seen so many developers slapping a tabindex=”0” on the neutral containers like <span> or <div> to create the custom interactive elements and forget to provide the necessary scripting. Reality check – tabindex attribute will only make the element focusable! You will have to provide the required event handlers along with the key listeners to make the element functional. Remember basics More importantly, people love tabindex=”0” so much that they go in and give it to non-interactive elements too assuming that screen readers use Tab to read content.

Myth 6: Sometimes we forget, beyond screen reader users’ other disability exists!

Fact: I have made the interactive element accessible for screen reader users. This I get to hear a lot! A custom interactive element will be used which will be only actionable using a screen reader. It won’t be reachable with a keyboard. If someone invites you to a party, but then forgets that you are even at the party. Hurts, right? We need to understand that beyond screen reader users, other disabilities exist – if you have made the interactive element accessible for screen reader users it doesn’t means that automatically it will be accessible for other people with disabilities. Someone who is using just a keyboard/switch device – how will they reach to the element and perform action? The interactive elements MUST be designed keeping inclusion in mind.

Myth 7: Role is not mandatory for interactive elements!

Fact: What’s the purpose of an interactive element? To perform an action – correct? If my interactive element is coded as <div tabindex=”0”>Activate Me!</div> to which all the required scripts are provided that makes it actionable using different input devices; my job’s done right? Answer is – you guessed it right, NO! How will a person using a screen reader understand the element is in fact actionable? Should they keep on guessing and activating the elements to understand if they are interactive? Sounds wrong right? Then define role! Role is an important piece of information that helps screen reader users understand the nature of element – like button, links, radio button, checkbox and so on.

Myth 8: Use of native HTML elements limits functionality

Fact: In simple words to say – this is another misconception. Functionalities like accordion, menus, draggable/droppable objects and so on can be perfectly created using native HTML elements. It’s the scripts that has to be handled accurately such that the accordion can expand/collapse content; menu button can open and close the sub menu and so on. Remember native HTML elements provide out of the box accessibility! So, it’s a win-win for everyone

Myth 9: If there’s design constraint to provide a visual text, then use aria-label

Fact: This is another of my favorites. If there’s no space to provide a visual text – provide aria-label to specify the accessible name. So easy, right? Wrong, providing aria-label means you have to hard code the accessible names! Remember? then developers complain about accessibility is a time-consuming process? Most of the sites use template logic wherein the structure will be set and based on the requirement additions/subtraction happens. But if you can utilize the visual text that is already available then why not? If it’s a form field, then a developer can definitely use title attribute to provide the accessible name. Remember, aria-label again is only available for a screen reader user – remember Myth number 6 we explored earlier? So, there is alternative like using aria-labelledby to provide an accessible name using the visual text that is already available.

Conclusion

And that’s a wrap, folks! I hope you enjoyed busting the above myths! By addressing these myths, Developers, Designers and Content Writers also understands the importance of accessible interactive elements and the benefits they bring to all users.

We’ve tried to bust some myths, separated facts from fiction, and hopefully gained some valuable insights on accessible interactive elements. I don’t remember where, but I read this somewhere which stuck with me – “Remember, the only thing that should be exclusive about your website is its content, not its accessibility”.

It’s important to remember that accessibility is not just a checkbox that needs to be ticked off, but a fundamental aspect of creating an inclusive digital space.

So, let’s keep on breaking down the barriers and making digital space more inclusive! Stay curious and keep busting those myths! Do share any additional myths that comes to your mind in the comment section below.

If you have any further questions or would like more information on accessibility reach out to us at info@barrierbreak.com. Also, if you want to know how our accessibility experts test your website and make it accessible, get in touch with our team at sales@barrierbreak.com.

This article by Fahad Lambate is a part of our BB Geek series where BarrierBreak team members share their expertise on accessibility and inclusion, drawing from their extensive experience in the field.

The post Busting Myths: Separating Fact from Fiction in Accessible Interactive Elements appeared first on Leader in Offshore Accessibility Testing | Section 508 Compliance | WCAG Conformance | BarrierBreak.

Some of us must have wished for an automated tool that could completely test a webpage for these requirements. That would make this task so much easier. But sadly, there is no such tool. While it is possible to automatically compute contrast ratio of some non-text elements, but it would need that colour (hex codes) is identified from CSS. Without colour identification, tools will struggle to find the right ratio. We will have to wait till such a tool with strong AI is developed. Anyway, understanding the success criterion is much more fun and manual testing is much more reliable.

In a nutshell, testing of contrast for non-text elements cannot be relied on automated tools. It requires manual testing to ensure that all required web page elements are thoroughly tested. It needs human judgement to ensure that only the elements in scope are examined.

As opposed to the title of this blog so far, we have only made it seem even more daunting. So, now let’s try and simplify it by logically dissecting and grouping its requirements. We shall also address the dilemma while testing contrast requirements of the infamous focus indicator.

As the success criterion is quite extensive, we will decode it in a series of blogs.

Overview of Success Criterion 1.4.11 Non-text Contrast

This success criterion was newly introduced in WCAG 2.1 in June 2018. It has been placed under the guideline 1.4 “Distinguishable” which is a part of the principle “Perceivable”. It has WCAG conformance Level of (AA), the minimum conformance level that products should try to achieve. Conforming with this success criterion ensures people with visual impairment, especially low vision users can identify important non-text information.

The success criterion 1.4.11 Non-text Contrast states: “The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(s):

User Interface Components

Visual information required to identify user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;

Graphical Objects

Parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.”

As the name itself suggests, it requires that non-text elements have sufficient contrast. Note that any form of text is separately tested for contrast under WCAG Success Criterion 1.4.3 Contrast (Minimum).

Basic Understanding for Testing

In general terms we can say, all informational non-text elements MUST have a minimum contrast ratio of 3:1 with its adjacent colours. Non-text is considered informational when it is relied upon to identify or understand the purpose of a component. From the normative definition, statements and examples on the understanding page, here is a derived methodology for finding contrast ratio of non-text elements.

Non-text contrast testing methodology key requirements checklist:

• Informational or Not – Find out if the non-text element is informational or not. If yes, proceed further. If no, not required to test further.
• Non-text Identification – Find out the key parts of non-text element that help in its identification or determining its purpose or both.
• Non-text element Colour – Find out the colour (hex code) of the identified non-text element.
• Adjacent Colour – Identify the adjacent colours (hex code) of non-text element which will impact its identification.
• Contrast Check – Check if the minimum contrast ratio requirement is met i.e., 3:1 or above between the non-text element and its adjacent colour. Contrast ratio can be found using any contrast checker tool.

* Key point to identify the adjacent colour
Adjacent colour is the colour next to the component. To identify the adjacent colour appropriately, it is critical to first identify the component itself. Adjacent colour may be identified differently based on the non-text element that needs to be tested.

For example, in case of a bordered input field with white internal and external background, the border becomes the key for identifying the input field. Hence, the border encompassing the white internal background helps to identify the component and white colour external background outside this border becomes the adjacent colour of the component.

In another example, a bordered input field has a dark external background and light internal background. The input is majorly identified based on the light internal background as the border gets visually absorbed within the dark external background. Hence, the light internal background becomes the component and dark coloured external background outside the input becomes the adjacent colour.

Basically, when a component is identified its surroundings with best possible contrast become its background. This contrast ensures its identification. Thus, the background provides us with the adjacent colour to find the contrast ratio.

CSS Hex Code vs Picker Hex Code

For accuracy, it is always recommended to take the hex codes of colours from the CSS whenever available. If the colour is not defined through CSS, then we should use the colour picker to find out the colours hex code.

Sometimes authors use the CSS property of ‘opacity’ to lighten the elements. In such cases a contrast tool that also considers the opacity (alpha value) should be used for computing the contrast ratio. Another way but not an ideal way would be to use a colour picker to directly find out the hex code of the colour with reduced opacity.

Conclusion

So far, we have covered the initial understanding and requirements of the success criterion. Other aspects and key areas of this success criterion will follow the same understanding. The same logic will be applied based on the component type. We shall apply the testing methodology on few examples in the upcoming blogs. Also, we shall discuss in more detail about testing graphical objects and user interface components along with their states in these blogs. So, watch out for the next blogs in the series!

For more information on how our accessibility experts test your website and make it accessible, get in touch with our team at sales@barrierbreak.com .

This article by Salim Khan is a part of our BB Geek series where BarrierBreak team members share their expertise on accessibility and inclusion, drawing from their extensive experience in the field.

The post Decoding WCAG 1.4.11 Non-text Contrast appeared first on Leader in Offshore Accessibility Testing | Section 508 Compliance | WCAG Conformance | BarrierBreak.

Back in August 2022, we had published a blog on WCAG 2.2 AQuick start Guide to find out what to expect from the new version of the guidelines. Since then two Candidate Recommendations of the guidelines have been released. The first one in September 2022 and the second one in January 2023. In this post, we will see what has changed from new success criteria’s, and removal of a success criteria to minor changes in the terms used in different success criteria’s.

The changes have been included at the start of each section of the below post for easy identification. In all there are 9 new success criteria’s being added in WCAG 2.2 as per the latest Candidate Recommendation. 1 success criteria, 4.1.1 Parsing is obsolete and has been removed from the guidelines. In addition, the conformance level for 2.4.7 Focus visible success criteria has changed from Level AA to Level A in WCAG 2.2. Out of these 9 success criteria’s: 

• 2 are at Level A 
• 5 are at Level AA 
• 2 are at Level AAA 

Level A 

4.1.1 Parsing

The Parsing success criteria is obsolete and has been removed from WCAG 2.2 guidelines. This criteria is no longer useful because the accessibility errors that fail under this criteria are already covered by other success criteria’s. Additionally, modern browsers and assistive technologies can handle parsing errors and thus they are no longer creating accessibility errors for people with disabilities. WCAG 2.2 is backward compatible, i.e. it covers success criteria included in both WCAG 2.0 and 2.1. Even though 4.1.1 Parsing is removed from WCAG 2.2, it has not been removed from WCAG 2.0 and 2.1 as of now. In the future, this can happen for sure but for now in order to conform to WCAG 2.0 and 2.1 one needs to yet test for 4.1.1 Parsing at Level A. 

3.2.6 Consistent Help

The first “Note” of the success criteria has changed. As per the note, the help mechanism can be either provided on the page directly or a direct link can be provided to the page that contains the information.

The purpose of this success criteria is to ensure that users can find help consistently at the same location across different pages of the website or application. Finding help at a consistent location is beneficial for users with cognitive disabilities who would like to access help when they are not able to complete any task, such as filling up a form.

Help on a website can be in the form of: 

• Contact information, email address, phone number, office timings
• Contact form, messaging application, chat application, social media channel
• Support page, FAQ page
• Chatbot 

3.3.9 Redundant Entry

The purpose of this success criteria is to provide users with an option to either select previously filled details or auto-populate the details. This will avoid the need to enter the information again by users in a multi-step form and is found very helpful by users with cognitive impairments. This success criteria can be met by providing users to select previously filled information in the form of a drop-down and they can simply select the details. Alternatively, users can simply tick a checkbox, such as Nominee address is same as Applicant’s address or copy and paste the textual information in the respective input fields.

Exceptions include: 

• Auto-populating the information will affect the security of the form.
• It is essential to enter the information again as it is part of the activity, i.e. in the case of a memory game. 
• Previously entered information is no longer valid.

Level AA 

2.4.11 Focus Appearance

The purpose of this success criteria is to ensure that the focus indicator for user interface controls is clearly visible and discernable. This will help users with mobility impairments and those with low vision who use a keyboard to easily locate their focus on the page.

The success criteria require that a visible focus indicator meets either one or both of the below-mentioned requirements: 

The entire focus indicator meets all the below requirements: 

• Focus indicator encloses the user interface component or sub-component that is focused, i.e. solidly surrounds the control. 
• Focus indicator should have a minimum contrast of 3:1 between its pixels and its focused and unfocused states. 
• Focus indicator pixels should have a contrast of 3:1 with the adjacent non-focused indicator colors.
• An area of the focus indicator meets all the below requirements: 
• Area of the focus indicator is at least 1 CSS pixel thick of the unfocused component or sub-component, or is at least 4 CSS pixel thick line along the shortest side of the minimum bounding box of the unfocused component or sub-component. 
• Area of the focus indicator should have a minimum contrast of 3:1 between its pixels and its focused and unfocused states. 

The area of the focus indicator pixels should have a contrast of 3:1 with the adjacent non-focused indicator colors or is not less than 2 CSS pixels. 

Exceptions include: 

• Focus indicator is determined by the user agent, such as web browsers.
• Focus indicator and its background is the default, i.e. generated by the browser and is not modified by the web page author. 

2.4.12 Focus Not Obscured (Minimum) 

The purpose of this success criteria is to make sure that when any user interface component receives focus, the component is not entirely hidden by any content created by the author. In order to meet this success criteria, some part of the component should be visible when it receives focus. For example, a non-modal dialog, sticky header/footer etc. can hide a focused component as well as its focus indicator. At any point, the user should be able to identify which component has focus currently on the page. This requirement is beneficial for people with low vision and those with mobility impairments.

2.5.7 Dragging Movements

The purpose of this success criteria is to help users carry out dragging functionalities through alternative means. People with dexterity impairments might find it difficult to carry out drag and drop activities or change values of a slider. Including an alternative method for functionalities based on dragging will help users accomplish their task easily.

A web page can provide users with drop-downs to select minimum and maximum price along with price range sliders in order to meet the success criteria. This success criteria does not apply to dragging movements that are part of user agents including assistive technologies and browsers. 

2.5.8 Target Size (Minimum)

In this success criteria, there are changes related to “Exceptions” for spacing and inline as well as “Note” for inline targets and line-height which are covered below. 

The purpose of this success criteria is to help users easily activate user interface controls and avoid unintentional activation of controls. When target sizes for controls are small users with mobility impairments who find to precisely control mouse movements will find it difficult to activate controls. Similarly, users browsing the web via mobile devices will also benefit by defining minimum target size of controls.

The minimum target size for pointer inputs is 24 by 24 CSS pixels. This requirement has the following exceptions:

• Spacing: The target does not overlap with any other target and has a target offset of at least 24 CSS pixels with every adjacent target. 
• Inline: The target is within a sentence or is in a bulleted or numbered list, or its size is otherwise constrained by the line-height of non-target text. 
• Essential: It is essential to present a target with smaller size than the minimum recommended 24 CSS pixels. 
• User Agent Control: Target size is determined by the user agent and not defined by the page author. 
• Equivalent: An equivalent control exists on the page that meets the minimum target size requirements. 

In the case of inline targets, the line-heights should be interpreted as perpendicular to the flow of text. So for language that is displayed top – to – bottom, the line-height would be horizontal.

3.3.8 Accessible Authentication 

Before the release of the first Candidate Recommendation, this success criteria was at 3.3.7. The first “Note” of the success criteria has changed. As per the “Note”, “Object recognition” and “Personal content” may be represented by images, video, or audio. 

The purpose of this success criteria is to provide users with an accessible, easy to use and secure means to login and perform tasks. Users with cognitive disabilities who might not be able to memorize usernames or passwords rely on copy and paste functions and password managers to enter their credentials. If a website uses scripts that block password managers or copy and paste functions, then it becomes difficult for users to login into their accounts and perform different tasks.

The success criteria requires that authentications are easy to use, accessible and secured. Authentication should not require cognitive function and if they are based on cognitive function than an alternate method is made available.

Cognitive function that requires users to recognize objects or provide content to the website is considered as an exception to the success criteria.

Level AAA 

2.4.13 Focus Not Obscured(Enhanced)

Before the release of the first Candidate Recommendation of WCAG 2.2 this success criteria was named as 2.4.12 Focus Appearance (Enhanced).

The purpose of this success criteria is to make sure that when any user interface component receives focus, the component is fully visible and is not hidden by any content created by the author. This success criteria is similar to 2.4.12 Focus Not Obscured (Minimum) and the only difference is that it requires that the focus be fully visible whereas as per 2.4.12, it is acceptable even if only some part of the focus is visible. 

3.3.9 Accessible Authentication (Enhanced)

As per the first Candidate Recommendation of WCAG 2.2 this success criteria was named as Accessible Authentication (No Exception). The criteria has now been renamed to Accessible Authentication (Enhanced). 

The purpose of this success criteria is to provide users with an accessible, easy to use and secure means to login and perform tasks. Users with cognitive disabilities who might not be able to memorize usernames or passwords rely on copy and paste functions and password managers to enter their credentials. If a website uses scripts that block password managers or copy and paste functions, then it becomes difficult for users to login into their accounts and perform different tasks.

The success criteria requires that authentications are easy to use, accessible and secured. Authentication should not require cognitive function and if they are based on cognitive function than an alternate method is made available. This success criteria is similar to 3.3.8 Accessible Authentication but does not include exceptions related to objects and user-provided content.

Would be great to see what the finally published WCAG 2.2 Guidelines looks like. The number of success criteria for meeting conformance will increase by 9 and take the total to 86 at Level AAA and 56 at Level AA if none of the above is removed! 

We would be happy to assist you with any questions or information you need related to WCAG 2.2 or accessibility. Get in touch with our accessibility consultant at sales@barrierbreak.com.

The post WCAG 2.2 – What to expect as per January 2023 Update! appeared first on Leader in Offshore Accessibility Testing | Section 508 Compliance | WCAG Conformance | BarrierBreak.

What is the European Accessibility Act?

The European Accessibility Act (EAA) Directive 2019/882 is a landmark European Union (EU) law that requires certain products and services manufactured and provided in the European market to be accessible for persons with disabilities. It follows a commitment on accessibility made by the EU and all Member States upon ratifying the United Nations Convention on the Rights of Persons with Disabilities. (UNCRPD).

The act sets out accessibility requirements for products such as computers, telephones, and televisions, and for services like banking and transport. The goal of the act is to ensure that people with disabilities can fully participate in society and enjoy the same opportunities as everyone else.

Businesses operating in the European Union (EU) should be ready for the European Accessibility Act (EAA) and start planning their accessibility journey now. As a pioneers in accessibility offshore, Barrierbreak can help businesses understand the importance of EAA and how they can ensure that their digital products and services are accessible and compliant.

Is the European Accessibility Act enforceable?

Yes, the EAA is a law and therefore enforceable. Till now the EU has required public-sector to adhere to accessibility requirements under the EU Web Accessibility Directive. But with the EAA, even the private-sector companies will be faced with an accessibility legislation.

When will the European Accessibility Act apply?

From June 28, 2025, businesses, manufacturers, service providers, and publishers will only be able to supply products and services in the European Market that comply with the Directive’s accessibility requirements.

The act requires Member States of the European Union to take the necessary measures to ensure that accessibility requirements are met for the products and services covered by the act, and to make these requirements binding and enforceable.

So, if you want to supply products and services to the EU then don’t wait, start implementing accessibility today!

What is covered under the European Accessibility Act?

The EAA will apply to the following products and services:

• Computers and operating systems
• ATM’s & Payment Terminals
• Electronic Ticketing Services
• Transport Service Information
• E-Readers & E-Books
• Websites & E-commerce
• Mobile device-based services including mobile applications.
• Banking Services
• Television & Media Services
• Telephony services

How will businesses benefit from the European Accessibility Act?

The European Accessibility Act will benefit businesses in several ways:

1. Harmonized market: The EAA sets out common accessibility requirements across the EU, which will reduce costs for businesses by eliminating the need to comply with different national standards.
2. Increased customer base: By making products and services more accessible to people with disabilities, businesses will be able to tap into a large and growing market of potential customers.
3. Improved brand reputation: Companies that are seen as leaders in accessibility will enhance their reputation and brand image, attracting more customers and employees.
4. Better innovation: Encouraging businesses to develop innovative accessibility solutions will drive technological progress and lead to new products and services that can be sold in both domestic and export markets.
5. Better compliance with laws and regulations: Complying with the act will ensure that businesses are in compliance with EU laws and regulations, reducing the risk of fines and legal action.

What will be the Impact of the European Accessibility Act?

The EAA is expected to have a positive impact on the life of 135 million people with a disability in the European Union and provide businesses with seamless cross-border trading.

Over the coming years, it is hoped that the EAA will ensure digital products and services are more accessible for people with disabilities, making it easier for them to participate in the digital economy.

How can BarrierBreak help?

If you are doing business in Europe, it is important to start planning for the European Accessibility Act now. Businesses that fail to comply with the EAA could face significant financial penalties and damage to their reputation. It is therefore important for businesses to take the necessary steps to ensure that their products and services are accessible and comply with the requirements outlined in the EAA.

We are an offshore digital accessibility company that provides accessibility consulting and accessibility testing solutions and assist businesses in complying with the European Accessibility Act in several ways.

By working with BarrierBreak, businesses can ensure that they meet the requirements of the EAA and provide accessible products and services to people with disabilities.

Get in touch with our accessibility consultant or write to us at sales@barrierbreak.com on how to prepare for the EAA and ensure that your business is compliant.

The post Are you ready for the European Accessibility Act? appeared first on Leader in Offshore Accessibility Testing | Section 508 Compliance | WCAG Conformance | BarrierBreak.

Digital transformation is the process of embracing new technologies to create better customer experiences. It’s also about adopting new ways of working and new ways of thinking that enable organizations to stay ahead of their competition. 

Digital transformation is a hot topic in the business world today. As technology evolves, organizations must adapt to stay competitive. Here are three digital transformation trends that are gaining popularity: 

Change management 

Businesses are changing rapidly with the use of digital technology. Change management trends are on the rise in the workplace. Implementing digital transformation can be a challenge for any organization. It is important for managers to be able to manage change and lead their teams through it. Digital adoption platforms are being used to facilitate and support change in many different ways. 

Growing cloud migration 

Another top digital transformation trend is the growing migration to the cloud. As businesses strive to become more agile and efficient, many are turning to cloud-based solutions to help them meet their goals. 

Use of advanced technology  

Finally, the use of advanced technology is also a top digital transformation trend. As businesses strive to stay ahead of the competition, they are turning to cutting-edge tech like artificial intelligence and machine learning to help them gain a competitive edge. 

Some companies have successfully transformed themselves from traditional businesses into digital businesses by using new technologies to reduce costs, increase customer engagement, and improve performance. Digital transformation has made it easier for people to access information and services.

But how accessible is this digital world for everyone? 

BarrierBreak is an internationally recognized and trusted accessibility vendor providing cost-effective accessibility consulting and digital accessibility services.

The changing landscape of digital accessibility  

Digital accessibility is an important topic that has been gaining momentum in the past few years. It is the responsibility of companies to make sure that their products are accessible to people with disabilities. As the world becomes increasingly connected and more people gain access to the internet, accessibility is becoming a priority for many organizations. 

There are a number of factors that are changing the landscape of digital accessibility.  

• An important factor that is changing the landscape of digital accessibility is the availability of advanced technologies to help people with disabilities assert their rights. In the past, many people with disabilities were unaware that they had any legal rights to access digital content and services. However, as the internet has become increasingly essential to daily life, people with disabilities have begun to demand greater access to online content and services.  

• Since the past 2-3 years, we have seen an increase in digital accessibility lawsuits. This trend is expected to continue in 2023 and beyond, as plaintiffs become more aware of their rights and the technology to help them assert those rights becomes more widely available. This increased awareness of digital accessibility rights has been fueled by a number of high-profile lawsuits against well-known companies, such as Netflix, Uber, and Sephora etc.  

What to expect in 2023? 

Mobile Accessibility 

As per Statista, the number of smartphone subscriptions worldwide today surpasses six billion and is forecast to further grow by several hundred million in the next few years. As the use of mobile devices continues to grow, it is important for businesses to consider how to maintain ADA compatibility across all mobile platforms.  

In recent years, the Department of Justice has focused on ensuring that mobile applications are also accessible to people with disabilities. In 2017, the DOJ issued guidance on how to make mobile applications accessible and compliant with the ADA. The guidance includes best practices for designing and developing accessible mobile apps, as well as tips for testing and deploying accessible mobile apps. 

Artificial Intelligence & Machine Learning 

Artificial Intelligence (AI) and Machine Learning (ML) are two of the hottest topics in the tech world right now. And it’s no surprise why – these cutting-edge technologies have the potential to revolutionize the way we live and work. From self-driving cars to automated customer service, AI and ML are already starting to change the world as we know it. 

There is a growing body of evidence that suggests that artificial intelligence (AI) and machine learning (ML) can be used to increase accessibility for people with disabilities. While AI and ML still have some limitations when it comes to accessibility, the potential is there to make a real difference in the lives of people with disabilities. As these technologies continue to develop, we can only hope that they will be used to make the world a more accessible place for everyone. 

Stricter Accessibility Laws  

Digital accessibility laws are an important part of making the digital world a more inclusive place for everyone. These laws help to ensure that everyone has equal access to digital content and devices, and that they can use them without barriers.  

As the world becomes increasingly digital, the future will focus on the importance of accessibility laws to keep up with technology.  

Conclusion 

Digital technology is advancing at an unprecedented rate and it’s changing the way we interact with the world. It’s also changing the way people with disabilities interact with the world. With digital accessibility, everyone can enjoy all of the benefits of digital technology. 

The recent trends in digital technology have been focused on making more things accessible to more people. Through better design and inclusive interfaces, everyone can experience the convenience and joy of using a computer or mobile device. 

To know more about our digital accessibility solutions and how we can help you in creating an accessibility roadmap, feel free to contact our digital accessibility experts. 

The post Rising trends in Digital Transformation and Digital Accessibility appeared first on Leader in Offshore Accessibility Testing | Section 508 Compliance | WCAG Conformance | BarrierBreak.

The post Are you looking for an accessible booking form for scheduling meetings? appeared first on Leader in Offshore Accessibility Testing | Section 508 Compliance | WCAG Conformance | BarrierBreak.

It’s no secret that the COVID-19 pandemic has had a devastating effect on the global economy. In addition, the Russian invasion of Ukraine and higher than expected inflation are all adding to the global slowdown. Many businesses have been forced to downsize or close their doors entirely. As per Forbes, the US economy may not officially be in a recession, but it’s not looking good. 

The current economic climate has forced many organizations to re-evaluate and re-plan their priorities and budgets. In the last 5 years, we are seeing organizations shift left and finally embracing accessibility. So now how do we keep the accessibility focus in these tough times?

BarrierBreak’s accessibility experts suggest five strategies to maintain your accessibility commitment in the economic slowdown:

1. Communicate the importance of accessibility to decision-makers

Make sure that decision-makers within your organization are aware of the importance of accessibility. They may not be aware of the business case for accessibility or may not realize how accessible products and services can benefit your customers.

Highlight customer or end-user stories to help them continue to invest in accessibility. Check our article on Higher Sales and a Business Win with Accessible Digital Products

2. Plan & strategize your Accessibility Roadmap

Remember, accessible products and services have a competitive advantage. The first step in meeting your accessibility commitments is to create a roadmap that provides an overall plan and strategy.  

Start with assessing your current state of accessibility for your digital assets such as websites, mobile apps, products, and/or services. It is critical to prioritize digital assets, plan resources, set milestones and goals based on business & customer’s needs.

3. Keep accessibility in mind when making budget decisions.

You might be worried that you’re going to come under pressure to cut your accessibility budget. You might well be right.

The Accessibility Roadmap will assist you to think of different models & approaches to deliver without reducing your accessibility commitments. Look at priorities, optimize processes & build efficiencies that can help you manage cost.

4. Train your employees on accessibility

Accessibility should be embedded into your organization’s culture, not treated as an afterthought. Create resources that can help them to do it right the first time like playbooks, checklists, video trainings. Invest in training people to implement accessibility as you design, build, test and deploy.

5. Time to adopt a Hybrid Delivery Model

Effectively plan the hybrid delivery models so as to optimize delivering on your accessibility commitment. Identify functions or processes that you can deliver with in-house and/or outsourced offshore resources. Find an offshore accessibility testing partner who can help your team to plan and implement accessibility into your digital solutions in the most cost-effective manner.

In conclusion, it would be difficult to avoid recession as inflation continues to rise. But it is also important to maintain your accessibility commitment in an economic slowdown. By doing so, you will be able to ensure that your products and services are accessible to all customers while also mitigating any legal risks. Additionally, you will be able to achieve a high level of customer satisfaction.

Reach out to the BarrierBreak team, we would be happy to work with you to develop a cost-effective delivery model for your accessibility requirements. There are various ways in which we can help you maintain your accessibility commitment in an economic slowdown. Our model will assist your business in high customer retention by making a significant impact and showing your commitment to accessibility. Additionally, through our expert services, we can design an accessibility roadmap for your organization that can generate higher satisfaction and revenue.

The post 5 strategies to maintain your accessibility commitment in an economic slowdown appeared first on Leader in Offshore Accessibility Testing | Section 508 Compliance | WCAG Conformance | BarrierBreak.

Food for thought

USD 8 trillion disposable income in the hands of disabled people and their families, but can they really shop on your online store? Research has demonstrated that none of the world’s top 50 websites meet the digital accessibility guidelines with more than one billion people, or 15% of the global population, reporting a disability affecting their ability to navigate websites.

BarrierBreak provides comprehensive retail accessibility testing solution that evaluates your business needs. Ensure your e-commerce websites & mobile applications conform to WCAG 2.0 & WCAG 2.1, and are Section 508 and ADA compliant. We also help you to create VPAT for your products and services to make it more attractive to government buyers and win more RFPs.

Retail trivia

Online shopping, also known as e-commerce, allows customers to buy goods and services directly from sellers on the website. It allows you to shop from the comfort of your home, at any time of day and any day of the year. On the other hand, sellers sell their products, regardless of whether the product is luxurious or meets the needs of the customer, on such portals. It can be difficult for people with disabilities to know what the product contains.

In 2018, consumers around the world spent a total of $2.8 trillion on online retail sales, a figure that could rise to $4.8 trillion in 2021. If you don’t consider the impact of online retail accessibility or web accessibility on your e-commerce revenue margins, you’re giving away a slice of the pie to retailers who make online retail accessibility their priority.

Let’s dive deeper

The Covid-19 pandemic has accelerated a shift towards online shopping especially for people with disabilities which requires the focus to shift towards digital accessibility.

Customers with a disability encounter many barriers when navigating retail websites. Despite the need to access digital content, most retailers do not see where their access problems lie.

Many of these obstacles are minor inconveniences, but others make navigating the site difficult or impossible without help. While online shopping has its own advantages, accessibility barriers on many e-commerce websites, makes it difficult for people with disabilities enjoy the same experience as everyone else.

The Compound Effect

Companies that prioritize e-commerce accessibility during the pandemic are more likely to see their websites prioritized by Google than by their competitors.

• E-commerce accessibility leads to the removal of barriers to online shopping for people with disabilities and enhances overall user-experience. Customers make their purchases in the traditional way by viewing what the product looks like and reading the description, and when the e-commerce website is accessible, everyone has access to similar information regardless of their disability but can also make their purchase with confidence.
• The accessibility of your online retail shop will bring you more customers than any other sector of the economy, which is reason enough for you to take an action now! Improving the accessibility of websites is a tangible improvement that thousands, even millions, of people will notice. Improving websites that facilitate access to essential goods for people with disabilities during quarantine can have an immediate positive impact on businesses.  
• Another reason to ensure an accessible e-commerce website is legal requirement. From 2017 to 2018, web accessibility lawsuits and litigations rose by 181 percent. If there are any inaccessible sections on your website, it can be deemed discriminatory against persons with disabilities, which violates the accessibility standards and guidelines such as Section 508, WCAG and ADA.

As online retailers are a for-profit business and disabled and elderly people are targeted markets, it is vital that they work hard to make their websites accessible to this demographic.

Why Online Retail or E-commerce accessibility is important?

Here’s what G3ICT has to say, “Committing to inclusive design not only makes a retailer’s website accessible to customers with disabilities, but also creates a shopping environment that is easier for all customers to use. Streamlined designs load quicker.”

Our team of highly experienced accessibility testing team at BarrierBreak which include testers with disabilities, ensures accessible e-commerce website. We ensure that your retail website is in compliance with the American with Disabilities Act (ADA) in accordance with the Web Content Accessibility Guidelines (WCAG ). Write to sales@barrierbreak.com to help us support you.

The post Why Online Retail should focus on Digital Accessibility? appeared first on Leader in Offshore Accessibility Testing | Section 508 Compliance | WCAG Conformance | BarrierBreak.