Yes, we are talking about “Smiling, Laughing, Kissing, Heart Eyes, Thinking, Angry” emojis. The ones that have become a part of our daily messages/emails. No matter if the messages are sent to friends, family, colleagues, or business stakeholders. Emojis help to add feelings to the messages. It’s also a great way to keep the tone of your message light.

Something like: “Happiest Birthday! Let’s plan a party at 21.00 today!”

Such an eye-pleasing birthday wish [Awww]. But is it the same for screen reader users? Let’s find out!

Screen reader users announce the birthday wish text as “Happiest Birthday! Cake Cake Cake Let’s plan a party at 21.00 today! Grinning face with big eyes”.

Oops! The message is not the same as I want to convey and also not enjoyable to hear all those unwanted expressions multiple times.

As we know screen reader announces the alt text of the image, we should try and use the most meaningful emojis (as per the context) along with the fact that it should be best to use them at the end of the statement or at the part that does not break the meaning of the message.

How are emojis generally used?

Everyone uses emojis differently such as someone would replace the text with emoji, someone will add many emojis along with the text, or someone will add an emoji that represents their emotions. Let’s have a deeper look at the emojis used.

Using emojis to convey messages

Sometimes emojis are too easy to use to convey a message. Like the feature to react to a particular text using emojis such as “thumbs up”, “thumbs down”, “Shocked”, and many more.

In the above bad example, the message that was to be conveyed was ‘Hey, I called you. Call me back once available’ but unfortunately, this is not coming out of the emojis. Instead, it announces “Hey, I ‘Telephone receiver’ you. ‘Telephone receiver’ me ‘Back arrow’ once available.”

Using emojis without text

Do you think using just emojis without any text is accessible to all users?

Nope, it’s not. Avoiding text and using only emojis impacts users with cognitive impairments users when the emojis are not the commonly used ones they in fact are confusing for all users.

Punctuation, Letters, Numbers! Oh yes, Emoticons!

:),  :-),  :-(,  :(,  :|,  these are a few examples of punctuation emoticons used across. These are announced as “colon right parenthesis”, “colon dash right parenthesis”, “colon dash left parenthesis”, “colon left parenthesis” and “colon vertical bar”. It will be annoying to listen to such announcements and the exact information will not be conveyed to users.

In the above bad example, the expression ‘speechless’ could not be communicated using emoticons.

Emoticons or Emojis is also = Unicode

Yes, emojis and emoticons look like images or icons, but they are characters from the UTF–8 character set.

‘128525’ will just mean some random numbers. However, using this random number along with the combination of ‘&#’ & ‘;’ in the HTML code will display smiling face with heart eyes emoji.

The unicode that will be used displays the same emoji/emoticons but with a different visual appearance on different platforms and with a different description of the emoji/emoticons. For example, an emoji can be called “Slightly smiling”, “Smiling face”, “Happy face” and so on.

To know more about emoticons/emoji Unicode check out the Unicode List. Let’s find out how different screen readers render emojis created using Unicode and <img> tag in HTML.

Emojis created using Unicode in HTML:

Using the code <p>&#128525;</p> in HTML, the generated emoji is announced as below by different commonly used screen readers:

But what if we want the accessible name to be uniformly identified on all platforms?
We can mark the emojis using <img> element and provide an appropriate and descriptive name. But yes this is only to enhance the user experience.

Emojis created using <img> tag in HTML:

When using a <img> tag along with an appropriate alternate text will render to all screen readers uniformly.

For example, creating an emoji as an image and providing an alternate text as below will announce as ‘Smiling face with heart shaped eyes’ to all screen readers on all platforms.

<img src="smiling-hearteyes.png" alt="Smiling face with heart shaped eyes">

This helps us to conclude creating emojis as images will help users render the same meaning across the platforms.

How to make emojis accessible?

Let’s check different ways to make the emojis accessible for all users.

Alternate text

Alternate text is important for understanding the emojis to assistive technology users. That does not mean providing alternate text when the emojis are used for decorative purposes on a webpage.

When the emojis are informative or/and interactive they should have an alternate text that describes them which will help the user to select the suitable emojis.

Alternative text should be concise and unique. For example, Happy face, Sad face, Angry face and so on.

<img src="angry.png" alt="Angry face">

<img src="angry.png" alt="Red circle with two dots and a brace bracket">

In the above bad example, the emoji is described per its visual appearance, however, it is difficult to conclude it indicates an angry face.

Colour Contrast

Emojis are presented using different colours like default, white, black and brown, giving users more options to select emojis. This adds up a task to ensure the emojis are visible in different modes like high contrast, dark mode and light mode. The emojis should meet the required contrast to help all users to identify the emojis.

Colour contrast requirements as per Success Criterion 1.4.11 Non-text Contrast:

• Identify all the key parts of a graphical object i.e., Emojis.
  • For example, in the case of a crying face emoji, the yellow circle face, the blue tears, black eyes and mouth are key parts of the emoji for a user to identify it as a crying face.
• Ensure that all the key parts meet the color contrast requirement of 3:1 with their adjacent colours.

Check out the Decoding WCAG 1.4.11 Non-text Contrast blog that explains the Non-text content requirements in layman’s language.

Note: Meeting Success Criterion 1.4.11 is only required when the emoji does not have any alternative to convey the same information in the surrounding.

Good Example:

In the above good example, the ‘heart’ emoji is clearly visible due to its sufficient contrast with background.

Bad Example:

In the above bad example, the ‘speechless’ emoji is not clearly visible due to its insufficient contrast with background.

Moving and Blinking Emojis

Many emojis move continuously like a clinking wine glass, a smiley with a thumb moving to indicate a like, moving eyes, and so on emojis. We must have seen such emojis on different platforms and even used some of these.

Watching them all move is delightful, but will it be the same for users with reading impairments, vestibular disorders and users with attention deficit disorders I guess NO.

One should avoid the auto movement of emojis. Even if auto movement is required it should only appear on keyboard focus or mouse hover. Also, the movement should be slow and stop within 5 seconds.

Good Example:

Using a Gif that stops within 5 seconds.

In the above good example, the Gif will be stoped after 5 seconds, not distracting users from page content or even having severe consequences.

Bad Example:

Using a Gif that cannot be stopped.

In the above bad example, the Gif will be played continuously, distracting users from page content or even having severe consequences.

CSS @prefers-reduced-motion media query

Use CSS @prefers-reduced-motion media query that ensures the page is displayed as per the user’s device setting for displaying animated content.

Animation can be displayed using the user’s device setting:

• On Windows to reduce the motion use Show animations in Windows
  • Steps: Settings > Display > Ease of Access
• On MacOS to reduce the motion use Reduce Motion
  • Steps: Settings > Accessibility > Display.
• On Android to reduce the motion use Remove animations
  • Steps: Settings > Accessibility > Text and display.

Hello!

Try the user’s device setting to turn off the animation.

Visual tooltip

(Again something that helps enhance user experience)

Yes, you read that correct! There are so many emojis that we have interpreted it wrong even today there are emojis that we do not know the real meaning of.

One of the best examples is folded hands emoji that many have thought of and used as a High Five emoji.

To avoid such misunderstanding for all the visual users it’s best to add a visual tooltip conveying the meaning of the emo

The tooltip does not have to be too descriptive or extra fancy. The tooltip text should be available on keyboard focus and on mouse hover. The requirement of 1.4.13: Content on Hover or Focus should be considered.

Do’s!

• Use colour combination for emojis that have sufficient contrast against all background modes like Default, Dark and High contrast modes.
• Provide concise alternate text that describe the emojis if you want all users to get an identical description.
• Use emojis instead of Emoticons to help the user understand the meaning of it.
• Use emojis in the statement where it makes the most meaning, preferably at the end of the statement.
•  Animated emojis should stop the motion within 5 seconds. If this is not achievable then the best solution is to provide a single play/stop button at the beginning of the page to control the animations. Alternatively, animated emojis should adhere to user device settings of controlling the animation.

Yippee! We have successfully understood the requirement to create accessible emojis for all users.

So, I hope now after understanding the requirement we all will be careful in which context to use emojis and how to ensure they will be accessible.

Let’s use accessible emojis and create delightful reading experiences for all!

The post Using Emojis is so fun! But how to make them accessible?  appeared first on Leader in Offshore Accessibility Testing | Section 508 Compliance | WCAG Conformance | BarrierBreak.

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.

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.

Featured Story

Why the GOV.UK Design System team changed the input type for numbers?

By GOV.UK

To provide users with a good service, government organizations usually need to collect data. Lots of data. The GOV.UK Design System team publishes patterns and components that let users enter their data in an easy and accessible way.

---

BarrierBreak Highlight

Become a BarrierBreak Trusted Partner!

Build inclusion by empowering your clients to build accessibility into their digital solutions and comply with accessibility standards & guidelines. Achieve digital accessibility at scale.

Apply Now

---

People Stories

Making microservices accessible!

By Craig Abbott

Almost anything can be made accessible. But, depending on how you build your microservice will determine how much work you have to do! Weigh up all your options. Make accessibility a priority. Lead by example.

---

Top Picks

New app to help products become more accessible for people with visual impairments.

By AT Today

New technology is helping products to be more accessible for people with cognitive impairments through an app called NaviLens, which allows users to scan products with a unique code using the camera of their device to obtain important information about the packaging and product, such as ingredients and instructions.

Android adds a dedicated Reading mode app for web pages and more!

By 9to5Google

Google has announced that as part of its expanded Accessibility functions, Android is gaining a new Reading mode capable of turning websites and other content into easier-to-read formats.

Achieve Digital Accessibility at Scale: Audit – Maintain – Comply

BarrierBreak is the Leader in Offshore Digital Accessibility Testing & Consulting. Your trusted adviser and reliable source for accessibility testing solutions. Get in touch with us to ensure your digital solutions conform to WCAG 2.1 & 2.0,  Section 508 Testing, and to create a VPAT for your product.

 

The post ACCESSIBILITY BUZZ – December 2022 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.

Featured Story

Disabled man joins European Space Agency's astronaut program

By BBC

The tight-as-a-drum labor market gives employers an incentive to maintain the remote-work benefit for disabled employees, which also helps companies diversify their workforces.

---

BarrierBreak Highlight

Accessibility is a journey and we are here to support you!

As a part of our CSR initiatives, we're pleased to announce our volunteering programA11y for Good is live! We support NGOs in their journey towards making their website accessible to all including people with disabilities. 

Read More

---

People Stories

Accessibility takes center stage as countdown to Qatar 2022 continues.

ByFIFA

Qatar 2022 will feature a number of firsts for disabled fans, including the availability of audio descriptive commentary in Arabic at all matches. Every match venue was built to exacting accessibility standards, including accessible parking, seating, bathrooms and concession stands.

---

Top Picks

Dems debut bill updating tech accessibility requirements for streaming, AI, and video conferencing

By Gizmodo

The Communications, Video, and Technology Accessibility Act, or CVTA, would amend key portions of the current federal accessibility law by, among other measures, requiring the improvement and expansion of closed captioning and audio description standards for online streaming platforms.

DOJ rules coming on web accessibility for state, local governments; businesses should pay attention too

By Corporate Compliance Insights

The DOJ has announced its intent to begin the rulemaking process to enact website accessibility regulations applicable to state and local governments under Title II of the Americans with Disabilities Act (ADA). This effort is a long-term action.

Achieve Digital Accessibility at Scale: Audit – Maintain – Comply

BarrierBreak is the Leader in Offshore Digital Accessibility Testing & Consulting. Your trusted adviser and reliable source for accessibility testing solutions. Get in touch with us to ensure your digital solutions conform to WCAG 2.1 & 2.0,  Section 508 Testing, and to create a VPAT for your product.

 

The post ACCESSIBILITY BUZZ – November 2022 appeared first on Leader in Offshore Accessibility Testing | Section 508 Compliance | WCAG Conformance | BarrierBreak.

Featured Story

Disabled Americans Reap Remote-Work Reward In Record Employment

By Financial Advisor The tight-as-a-drum labor market gives employers an incentive to maintain the remote-work benefit for disabled employees, which also helps companies diversify their workforces.

---

BarrierBreak Highlight

Web Accessibility for Speech Recognition Users - A Pragmatic Approach

Speech recognition technology has come a long way in recent years. This technology enables computers to understand and interpret human speech. There are many different applications for speech recognition, from voice-activated assistants to hands-free control of devices. 

Read More

---

People Stories

A ‘game-changer’ for millions of Americans: You can now buy hearing aids over the counter!

By CNN Health

Now, instead of getting a prescription and having a custom fitting with a hearing health professional, adults can buy hearing aids directly from a store or online. Some doctors estimate that 90% of the population with hearing loss could benefit from these over-the-counter devices.

---

Top Picks

Need to ensure greater accessibility for people with disabilities: Justice Chandrachud

By The Indian Express Supreme Court Justice Chandrachud called on government & private entities to work towards a more just world for people with disabilities while noting the lack of accessibility for them in public & other spaces.

How ‘God Of War’ Made Accessibility A Core Part Of Its Game Design

By News Azi The 2018 release of God of War did provide some accessibility features such as customizable controls, speaker indicators for subtitles, and the option to skip quick-time events. However, it lacked other crucial options. Shortly after God of War’s 2018 launch, the team began to work on developing an extensive set of accessibility tools for disabled players.

Achieve Digital Accessibility at Scale: Audit – Maintain – Comply

BarrierBreak is the Leader in Offshore Digital Accessibility Testing & Consulting. Your trusted adviser and reliable source for accessibility testing solutions. Get in touch with us to ensure your digital solutions conform to WCAG 2.1 & 2.0,  Section 508 Testing, and to create a VPAT for your product.

 

The post ACCESSIBILITY BUZZ – October 2022 appeared first on Leader in Offshore Accessibility Testing | Section 508 Compliance | WCAG Conformance | BarrierBreak.

Featured Story

DOE Releases First-Ever Plan to Advance Diversity, Equity, Inclusion and Accessibility

By Energy.Gov The plan outlines Departmental actions to sustain an inclusive and accessible work environment by strengthening recruitment, retention and promotion, while removing inequitable barriers to advancement and development opportunities.

---

BarrierBreak Highlight

Why Mobile apps in India need to take Accessibility seriously?

RPWD mandates accessibility & CCPD on digital accessibility. In a recent order, the Chief Commissioner for Persons with Disabilities (CCPD) stated that private establishments are also bound by the digital accessibility requirements under the Rights of Persons with Disabilities Act, 2016 ( RPwD Act).

Read More on the Mandate

---

People Stories

This technology makes data accessible to blind and visually impaired people.

By NPR

NPR's Mary Louise Kelly talks with Mona Minkara, a professor of bioengineering at Northeastern University who is also blind, about a new way to present science data to blind and sighted people alike.

---

Top Picks

Change your approach to accessibility and get a better developer experience

By Dev When we talk about web accessibility most of us think of blind people, or maybe someone that can’t use a mouse. That’s not wrong, and they are an important target group, but website accessibility is about more than supporting screen readers and tab-navigation.

Study of travelers with disabilities reveals major accessibility issues with lodging and transportation

By Hotel News Resource The survey found lodging and transportation accessibility are cited as the two biggest barriers to travel for those with mobility issues. Nearly all respondents (96%) say they have faced an accommodation problem while traveling, while 86% have experienced flight problems and 79% have experienced in-market transportation problems.

Achieve Digital Accessibility at Scale: Audit – Maintain – Comply

BarrierBreak is the Leader in Offshore Digital Accessibility Testing & Consulting. Your trusted adviser and reliable source for accessibility testing solutions. Get in touch with us to ensure your digital solutions conform to WCAG 2.1 & 2.0,  Section 508 Testing, and to create a VPAT for your product.

 

The post ACCESSIBILITY BUZZ – September 2022 appeared first on Leader in Offshore Accessibility Testing | Section 508 Compliance | WCAG Conformance | BarrierBreak.

Featured Story

Regina Folk Festival piloting accessibility project using hearing loop

By LeaderPost The Regina Folk Festival (RFF) is piloting a project at this year’s event with the aim of improving accessibility for the hearing impaired at future shows with the use of a Hearing Loop. It converts audio to a magnetic signal, which is transmitted to a person’s hearing aid, implant or headset and those within the loop can utilize its capabilities to hear the entertainment better by eliminating background noise.

---

BarrierBreak Highlight

WCAG 2.2 – A Quick Start Guide

Web Content Accessibility Guidelines 2.2 is scheduled to be published by December of 2022. The candidate recommendation is expected in September 2022 and thus it is the right time to figure out what WCAG 2.2 version has in store for us.

Read More on WCAG 2.2

---

People Stories

The ADA was a victory for the disabled community, but we need more.

By NRP

"Growing up, I always used crutches to get around, and only would use a wheelchair for school field trips or vacations that involved long-distance walking; ableism and issues of inaccessibility are part of the reason why"

---

Top Picks

Could this tool improve customer service for disabled people?

By Metro There are currently more than 14 million disabled people in the UK, half of which are of working age. A Scottish-based tech company has come up with an idea to let shops and businesses know when disabled customers are arriving, as well as how to help them.

Minnesota State Fair focused on addressing accessibility for all

By InForum In recent years, the State Fair has taken the wide issue of accessibility and brought it to the forefront of their planning. They offer an extensive accessibility guide including ASL interpreting services and sensory-friendly visits.

Achieve Digital Accessibility at Scale: Audit – Maintain – Comply

BarrierBreak is the Leader in Offshore Digital Accessibility Testing & Consulting. Your trusted adviser and reliable source for accessibility testing solutions. Get in touch with us to ensure your digital solutions conform to WCAG 2.1 & 2.0,  Section 508 Testing, and to create a VPAT for your product.

 

The post ACCESSIBILITY BUZZ – August 2022 appeared first on Leader in Offshore Accessibility Testing | Section 508 Compliance | WCAG Conformance | BarrierBreak.