While exploring Pune city with my friends, we decided to book bus tickets through a web site for our convenience. Although the booking process initially took some time, I was able to complete it within minutes. Intrigued by my quick booking, my friend asked me how I managed to do it so efficiently. They had trouble navigating the web on iPhone and iPad with VoiceOver screen reader because they were navigating through web content using only swipe gestures. They wanted to know if there are any shortcuts available on iPhone and iPad to navigate the web, similar to the way desktop screen readers like JAWS, NVDA, Narrator, and others use quick navigation keystrokes.

So, I thought of writing an article on ‘navigating web with VoiceOver rotor on iPhone and iPad’. To begin with, let's start with understanding the rotor.

What is rotor in VoiceOver?

VoiceOver is a built-in screen reader found on all iPhone, iPad and Mac devices. The rotor is one of the features of the VoiceOver, which lets you navigate through a set of elements on the web, apps and system utilities as follows: 

• Increase/decrease Volume 
•  Increase/decrease the speech rate. 
•  Reading methods i.e., character, word, line and so on.
• Navigate through headings, lists, links and so on the web pages. 

How do you use rotor on iPhone and iPad? 

First, to turn on VoiceOver:

1. Go to "Settings". 
2. Select the "Accessibility" option. 
3. Select the "VoiceOver" option. 
4. Activate the "VoiceOver On" switch. 

To use the rotor, follow the below steps:

1. Rotate two fingers on the screen of an iPhone or iPad device as if you are turning a dial either clockwise or anticlockwise.
2. The VoiceOver will read out the first rotor option. 
3. Keep rotating your fingers to hear more options. 
4. Lift your fingers to choose an option from the rotor. 
5. By flicking up/down one can access the selected options on the screen.

The elements of the rotor options change based on the application in use at any given time. For example, if you choose the heading option when a web page is open, a flick down or up will move VoiceOver to the next or previous heading on the web page. 

With rotor options, we can move to the next element by Flicking down and move to the previous element by flicking up with one finger. If you swipe left and right on the screen, VoiceOver will read out the next item on the page. 

One more important thing about the rotor feature is that, if we choose any option then VoiceOver announces the number of elements present on the web page for the selected option. 

For example, when a user selects "headings" option in the rotor on BarrierBreak’s home page, VoiceOver announces "13 headings". 

Rotor Options and their actions

The following tables show the Rotor Options and their actions for navigating the screen content and some system utilities. 

Note: Rotor options and actions mentioned in this post are as per iOS 16.5.

In this post, I have covered rotor options related to web and some basic actions.  

Reading options

Rotor options	VoiceOver Action
Character	Moves to next/previous character
Word	Moves to next/previous word
Line	Moves to next/previous line

System utilities options

Rotor options	VoiceOver Action
Speech rate	Increase/decrease speech rate
Volume	Increase/decrease volume
Container	Move VoiceOver focus from one container to another. For example, Doc area to the home screen.

Web element options

Rotor options	VoiceOver Action
Heading	Moves to the next/previous heading
List	Moves to the next/previous list
Table	Moves to the next/previous table (focus stay at the beginning of table)
Button	Moves to the next/previous button
Form control	Moves to the next/previous form control (check box, radio buttons and so on)
Text fields	Moves to the next/previous text field
Search fields	Moves to the next/previous search field
Links	Moves to the next/previous links
Visited links	Moves to the next/previous visited links
Unvisited links	Moves to the next/previous unvisited links
In-Page Links	Moves to the next/previous In-Page Links
Images	Moves to the next/previous images
Landmark	Moves to the next/previous landmark (Banner, main and so on)
Same element	Moves to the next/previous same element

Some of the default options of the rotor are "Headings", "Links", "Form controls", "Containers" and so on. VoiceOver provides users with an option to customize the options that come up in the rotor. To customize the rotor options, perform the following steps:

1. Go to "Settings".
2. Select the "Accessibility" option.
3. Select the "VoiceOver" option. 
4. Select the "rotor" option. 
5. Choose rotor options that you required such as "Table", "Landmark", "Unvisited links", "Visited links" and so on. 

So far, we discussed about the different rotor options of VoiceOver, now let’s discuss the rotor actions. 

What is rotor action?

The rotor actions are another feature of VoiceOver which allows user to perform action on apps. This feature was introduced in iOS 14. 

• Edit apps on home screen: This function enables the user to "Drag" and "Delete" for apps on the home screen. 
• Direct touch in apps: Direct touch is a way in which user can tell VoiceOver to ignore touch events in part or all on an app's screen so that the app can handle those touch events directly. 

To configure rotor actions, perform the following steps:  

1. Go to the "Settings" 
2. Select the "Accessibility" option. 
3. Select the "VoiceOver" option. 
4. Select the "rotor action" option. 

Browsing with VoiceOver Rotor 

Now let’s see the rotor in action. I’ll be downloading the "SAAS Accessibility Toolkit" from the BarrierBreak website. 

1. Open BarrierBreak website in safari browser. 
2. Select "headings" option in the rotor. 
3. By Flicking down with one finger, navigate to "Accessibility Consulting" heading. 
4. Navigate to "Download now" button using right swipe and double tap to activate it. 
5. Next, select "Form controls" option in the rotor. 
6. By Flicking down with one finger, navigate to "Name", "Corporate Email", "Company", "Industry" form fields and fill up the details. 
7. Swipe right and navigate to "Request Toolkit" button and double tap to activate it. 

Wasn’t it fast and easy?  

The VoiceOver rotor is a powerful tool that allows users with visual impairments to navigate the web effortlessly on their iPhones and iPads. And now that you have an understanding of the various rotor options used for web navigation, it is time to acquaint yourself with VoiceOver and take your accessibility journey in web navigation to the next level! 

Share your thoughts in the comments section below, and let's continue the conversation on creating a more inclusive web for all.

Useful VoiceOver Resources: 

• Getting started with VoiceOver on iOS
• Getting started with VoiceOver on Mac

The post Navigating web with VoiceOver rotor in iPhone and iPad  appeared first on Leader in Offshore Accessibility Testing | Section 508 Compliance | WCAG Conformance | BarrierBreak.

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.

Voice Access on Android 

Voice Access is used to navigate and interact with Android devices using voice commands. 

Basic Requirements 

• Introduced in Android Version 7 and later. 
• Working microphone in Android device for users to give commands. 
• Download Voice Access from Google Play store. 
• Google Assistant should be activated on the device such that users can switch on Voice Access even by giving the command “Turn on Voice Access”. 

Turn Voice Access On or Off 

1. Go to Device Settings  
2. Select Accessibility and then tap Voice Access
3. To start using Voice Access, tap the Voice Access activation button

Tip: You can set up the activation button in Settings  > Accessibility > Voice Access > Settings > Activation button.

Interact using Voice Access 

Activate Voice Access 

After tapping on Voice Access activation button , the text “Voice Access on ” is displayed on screen to indicate that user can give voice commands to perform actions. They can use “Stop Listening” command to stop Voice Access. 

Activate Elements 

We can activate elements using voice commands such as “Tap” followed by the name of the elements. 

Basic Commands to interact with Voice Access 

• Show labels – This command displays an overlay with the name of the elements along with numbers. Users can say label name to activate the respective element. For Example, if users say, “Navigate Up” on Accessibility Settings screen, it will take users to the previous screen. 

• Show numbers – This command displays an overlay with number tags for the elements. Users can say “Tap number” or just the number to activate with respective item. For Example, if users say, “Tap 10″, it will activate the Accessibility Menu button on Accessibility Settings screen and take them to the Accessibility Menu screen. 

Tip:  Users can quickly find out the description of numbered element using “What is [number] ?” Command. 

• Show grid – This command displays numbered grid overlay and user can say “Tap number” on the grid to enlarge that area which will then present a new set of grid overlay. For Example, if users say “Tap 18” it will open an enlarged view of the grid that will display more numbers. Again, when users say, “Tap 8”, the Display & brightness button on Settings screen will get activated and they will be taken to Display & brightness screen.    

Tip: More information on how to interact with Voice Access can be found on https://support.google.com/accessibility/android/answer/6151848

Let’s explore opening the browser, to open the browser give the command “Open Chrome”. Now that we have opened the browser, let’s go ahead and open a website and say the following commands: 

1. Use the “Tap Address” command to navigate to the Address Bar. 
2. Dictate the Web address. (For example, https://www.barrierbreak.com/image-description/) 
3. Use the “Tap Go” command to activate the “Go” button to access the screen.

Now to navigate through the Image description screen, whether it is to a link, button or form controls, use the following commands. 

• Tap element name  – To directly activate a link or button. 
• Scroll Up or Scroll Down – To go up and down a screen. 
• Go back – To navigate to previous screen.                

Don’t you feel speech recognition is fascinating? It has come a long way in recent years, and with the way it is being evolving will definitely only lead to more improvements. These features can make it easier for users with any disabilities to interact with their devices and perform a wide range of tasks using their voice. 

Utilizing Voice Access on your Android device can greatly enhance your experience and accessibility. By following the steps outlined in this blog, you can easily get started with voice access and enjoy its rich set of features.   

Hope this series of blogs helps you to get started with the speech recognition in Android and iOS. Feel free to drop in your comments and share your experiences of using Voice Access! 

Happy exploring !! 

Looking for a reliable digital accessibility partner that truly understands your commitment to inclusion and accessibility? Why settle for anything less than the best? Choose us as your accessibility vendor and take the first step towards a truly inclusive digital future. 

This article by Jayshree Sharma 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 How to get started with Voice Access (Android)? 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.

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.

Speech recognition will also be helpful when we find ourselves in a situation where our hands are occupied but need to perform a task. For example, we are in a crowded place and need to make an urgent phone call. Simply give the voice command and get the task done. Yes, we can do this with voice assistants like Siri and Google Assistant but speech recognition goes beyond these!  

Let’s delve into the basics of using built-in speech recognition on iOS! 

Voice Control in iOS 

Using Voice Control, we can navigate and interact with our iOS devices using different voice commands. 

Basic Requirements 

• Introduced in iOS 13 and available for later versions as well. 
• Working microphone in iOS device for users to say commands. 
• Active Internet Connection is needed to download required files for first time setup. 
• Siri needs to be setup in iOS device such that users can switch on Voice Control even by using the command “Turn on Voice Control”. 

Tip: Wi-Fi needs to be turned on when using Voice Control for the first time to download initial setup. 

Turn Voice Control On or Off 

1. Go to Settings icon  and select Accessibility.
2. Select Voice Control, then select Set up Voice Control which will initiate a download for initial setup.  
3. When the download is complete, a microphone icon will appear in the status bar of your device.

Tip:  Microphone icon in status bar indicates that Voice Control is enabled or not. 

Interact using Voice Control 

Wake up your device 

We can use the voice command “Wake up” to make your device start listening with a command and for it to stop listening, use the “Go to sleep” command. 

Activate Items 

We can activate items using voice commands such as “Tap” followed by the name of the item. 

Basic Commands to interact with Voice Control 

• Show names – This command displays an overlay with the name of the items. Users can say “Tap item name” to activate the respective item. For example, on Voice Control screen of Accessibility Settings – if users say, “Tap Language”, it will activate the Language button and take them to the Language screen. 

Tip: Switch on “Show Hints” from the Settings > Accessibility options > Voice Control  to get suggestions for Voice commands. 

• Show numbers – This command displays an overlay with number tags for the items. Users can say “Tap number” to activate with respective item. For example, on Voice Control screen of Accessibility Settings – if users say, “Tap 3”, it will activate the Zoom button and take them to the Zoom screen. 

• Show grid – This command displays numbered grid overlay and user can say “Tap number” to enlarge that area which will then present a new set of grid overlay. For example, on Voice Control screen of Accessibility Settings – if users say “Tap 12” it will open an enlarge view of the grid that will display more numbers. Again, when users say, “Tap 2”, Zoom button will get activated and they will be taken to Zoom screen. 

Tip: More information on how to interact with Voice Control can be found on https://support.apple.com/en-in/guide/iphone/iph2c21a3c88/ios  
 
Let’s explore opening the browser, to open the browser give the command “Open Safari”. Now that we have opened the browser, let’s go ahead and open a website and say the following commands: 

1. Go to the Address Bar by giving the command “Tap Address” when names of items shown on screen via Show Names command. 
2. Dictate the Web address. (For example, https://www.barrierbreak.com/vpat-creation/) 
3. Say the command “Tap Go” to navigate to the screen. 

Now to navigate through the VPAT creation screen, whether it is to a link, button or form controls, use the following commands. 

• Tap item name – To directly activate a link or button. 
• Scroll Up or Scroll Down – To go up and down a screen. 
• Go back – To navigate to previous screen. 

Tip: We can explore few more commands by saying the “Show Commands” with Voice Control turned on. 

Don’t you feel speech recognition is fascinating? It has come a long way in recent years, and with the way it is being evolving will definitely only lead to more improvements. These features can make it easier for users with any disabilities to interact with their devices and perform a wide range of tasks using their voice. 

Utilizing voice control on your iOS device can greatly enhance your experience and accessibility. By following the steps outlined in this blog, you can easily get started with voice control and enjoy its benefits.  

If you’re an Android user, don’t worry – we’ll be covering how to get started with Voice Access in Android in our next blog post. Be sure to keep an eye out for the next entry in this series! 

Looking for a reliable digital accessibility partner that truly understands your commitment to inclusion and accessibility? Why settle for anything less than the best? Choose us as your accessibility vendor and take the first step towards a truly inclusive digital future.

This article by Jayshree Sharma 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 How to get started with Voice Control (iOS)? 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.

I completed my degree, I secured a job, and all seemed to be going on smoothly. I was slowly but surely starting to achieve my goals and aspirations. However, unexpectedly and abruptly, life took a major turn. It came to a complete halt! 

You may be curious as to what transpired. My circumstances resembled that of an individual, soaring at great heights in the sky, only to plummet into a valley below. Let’s rewind. 

I graduated with a degree in computer science and engineering. I got a job at an on-campus interview and was ready to fly high with my dreams and career, but this is life! We do not know what will happen in the next moment. 

One day I was not feeling well and went to a doctor for treatment, and during the treatment, I lost my eyesight due to a drug reaction. Since I was born with normal vision and had no eyesight problems, nor did I ever wear glasses, it was very hard for me to digest the fact that I could no longer see and had lost my vision. 

Coping with vision loss 

My life came to a complete stop because as a computer technician, I was no longer able to see and work on the computer. I do not know what happened. Thousands of questions, and was not able to think of anything good, I was completely broken from the inside and did not know how to continue and what to do next. I was not able to use my phone, read any books, go outside, work on the computer, travel alone, and many other things and I felt like I was living in a nightmare. 

I was not aware of what lay ahead for me as there was no one to help me and guide me. My parents were also very sad and did not know what to do and tried to find a solution. 

Discovering Assistive Technology 

During the treatment, I visited one of the famous hospitals in India where a doctor suggested me a rehabilitation center and showed me how people with visual impairment live their lives, learn many things, and solve challenges. One of the staff took me to the computer lab and what I saw there amazed me. One of the instructors who was visually impaired, shared her knowledge and experience with computers and cell phones, how they use them and work with them. 

She turned on her computer, opened Gmail, quickly logged in, opened the inbox, composed a message, and sent it to me. I was shocked because within a split second she was doing all the tasks on one computer and as I watched it all happen, I was speechless and got goosebumps. I felt like OMG! I felt like fate has given me a new life and a new opportunity. 

The moment I experienced this and understood that life never ends, I found a new turning point in my life as ‘Assistive Technology’. Technology that supports me to learn, grow and live my life like others. At a point where I had lost all my hopes and dreams, this technology became my guide and mentor and helped me get back to my life. 

At first, it took me some time to learn and understand how it works because I was a sighted computer user before I lost my vision and the transition to learning how to use computers with screen readers took some time, but I learned and now I can say with confidence that I can work on the computer, read newspapers, do online transactions and online shopping, and much more. 

After learning computers with JAWS (Job Access with Speech) and NVDA (Non-Visual Desktop Access) and magnifier in Windows 10, I learned assistive technology in cell phones such as Talkback in Android and Voiceover in iOS, which made my life smoother and gives me back the confidence that “I CAN”. 

The power of assistive technology 

I am happy to share that this turning point of ‘Assistive Technology’ has changed my life and other people’s views, even though I am a person with visual impairment – how I use computers, laptops and mobile devices and do my daily work and also help others when needed. It was like a boomerang for me. 

During my journey with assistive technology, I became acquainted with the term ‘accessibility,’ which was completely new to me. To learn more about it, I enrolled in a small course. There, I discovered that accessibility is a platform that can help me build a career and find employment, while also allowing me to contribute to making the digital world more accessible.  

Accessibility to the rescue 

Through my studies, I was fortunate enough to secure a job at BarrierBreak, one of the most reputable digital accessibility companies in India. Here, I have gained a deeper understanding of assistive technology and how it can be used to make digital products more accessible. In my role as an Associate Accessibility Tester, I test and suggest various remediation techniques to ensure that digital products like websites and mobile apps are more inclusive and accessible to individuals like me, who rely on screen readers to navigate their daily lives.  

BarrierBreak: a place of Inclusion, Growth, and Support

I consider myself incredibly fortunate to have been given the opportunity to work at BarrierBreak, a company that not only offers equal opportunities for growth and development but also emphasizes the importance of staying up-to-date with the latest technologies and best practices. Through both training and hands-on experience, I have gained a deeper understanding of web and mobile apps accessibility, WCAG, ARIA, and A11Y concepts, which has bolstered my confidence in my role. 

What makes BarrierBreak different is the feeling that everyone is part of a team and that everyone helps and supports each other. I have been fortunate to work alongside a team of the best mentors, who have consistently been available to help me grow and provide the best solutions to clients.

As a member of the BarrierBreak family, I have learned to embody the company’s core values of I3ON – Inclusion, Innovative, Integrity, Ownership, and Nurture – which have served as a guiding force in both my professional and personal life. I am deeply grateful to assistive technology and to BarrierBreak for providing me with this opportunity, and I sincerely hope that it serves as a turning point for many others, enabling them to lead smoother, happier lives. 

This article by Gayatri Murthy 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 Turning point: The day when assistive technology came into my life appeared first on Leader in Offshore Accessibility Testing | Section 508 Compliance | WCAG Conformance | BarrierBreak.