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

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

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

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

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

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

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

Download Now

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

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

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

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

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

Myth 2: The accessible interactive elements are visually boring

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

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

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

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

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

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

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

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

Myth 4: Scripted interactive elements can be accessed by all

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

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

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

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

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

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

Myth 7: Role is not mandatory for interactive elements!

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

Myth 8: Use of native HTML elements limits functionality

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

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

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

Conclusion

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

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

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

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

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

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

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

My experience of Drag & Drop largely revolves around games, along with the day-to-day activity where I need to move files or mails from one place to another. Yes, it’s that simple! Drag a file and Drop into another location.

Having said this, I was involved in serious gaming before, which consisted of MMORPG’s (Massively Multiplayer Online Role-Playing Game) where I used to meet the players online to form a sort of clan (group) to complete various objectives. Once, the members from different clan along with mine planned for a Meetup at an HQ (Game Headquarters). This is where, I met one of my clan member Nemanja, for the first time in a person. He brought along his brother Aleksandar. His brother was a visually impaired person. Although what I heard from Nemanja was that, his brother was an avid gamer as well. That intrigued me! Wouldn’t anyone be? So, I got talking to Aleksandar to understand what kind of technology provides him the ability to perform different task along with the gaming. I then found out, he was using different kind of screen readers like JAWS, NVDA, Narrator, etc.

Honestly, it was pretty cool to see, what I was able to do using a mouse and keyboard with the help of my vision, he was able to do with a screen reader and a keyboard. Aleksandar then offered me to play a game of Tic Tac Toe with him, which I was really excited to, knowing he would be using a screen reader and a keyboard to place the “X” and “O” in the respective block. I have to say I lost that game, but I got to learn something as well. After talking more with Aleksandar, he said how accessible the game was which made him to play it smoothly. Then we also talked about other games.

We wouldn’t want to dive into high end gaming here, would we? Nah, that is completely a different level of complexity and we don’t want to go there for now. Who knows maybe some other day . So, coming back to the topic, the idea behind working of a Tic Tac Toe is? Yeah you guessed it right! A drag and drop logic!

Drag & Drop functionality is basically performed within a graphical user interface (GUI). In layman’s term, it involves moving a pointer over an object, selecting it, and moving it to a new location. It’s that simple!

In day to day world, drag and drop is being used for multiple purposes. For example, you can drag and drop an icon on the desktop to move it to a folder. You can perform drag and drop on an open window by activating the title bar and moving it to a new location. Other examples would be programs allowing you to open the files by dragging and dropping file icons directly onto the application icon. On a website, drag and drop functionality is used for various games or questionnaires as well. Having said this, on the contrary it is not an easy task to make the drag and drop functionality accessible. Although, it’s not impossible!

“Dragging” the object in Drag & Drop 

• If you are using a mouse, you can drag an object by clicking the mouse button to select an object, then moving the mouse while keeping the mouse button pushed down. This is called dragging of an object.
• If you are using a touchscreen device, you can select an item by simply touching it with your finger. (For selecting an object, some interfaces may require you to hold your finger on the object for a second or two.) Then you can drag the item by moving your finger across the screen to desired place.

“Drop” the object in Drag & Drop

• Using a mouse, once you have moved the object where you want to place it, you can release the mouse button to drop the object in the new location.
• While using a touch screen, simply lift your finger off the screen to drop the object.

“Drag & Drop” interaction for a keyboard and screen reader users

We will cover here about creating accessible Drag and Drop functionality; including ARIA and non-ARIA techniques i.e. using a standard HTML. Specifically, to achieve equal functionality for all user types, keyboard and mouse events must be cross-referenced, and accessible feedback must be provided to convey the role, state and response of draggable objects to screen reader users.

While making any interaction accessible with both the keyboard and for screen reader users, fundamentals are necessary i.e. providing three basic pieces of information: identity, operation, and state.

For a user interacting with an element, as basic as a checkbox, or as complex as drag and drop experience, we need to ask ourselves at least the below three questions:

1. Identity: What element I am interacting with?
2. Operation: How do I access the element?
3. State: What is the current state of the element?

The most important thing to be aware while creating an accessible drag & drop is the infallible scripting using JavaScript to ensure that all draggable elements are accessible from the keyboard. ARIA won’t be doing this automatically by itself!

Since we all are so familiar with the use of ARIA-Grabbed and ARIA-Dropeffect which will convey Draggable, Grabbed, and a subset of drop effects such as Droppable, along with the state of grab i.e. when grab is set to true, it has been selected for dragging, supported indicates that element is grabbable, but is not currently grabbed, false indicates the object is not grabbable (default). This may or may not fit the desired functionality. But did you know, these attributes are deprecated in ARIA 1.1?

So, the idea here is now to use native accessibility API features for drag and drop instead along with some use of basic ARIA.

It is critical to keep in mind; an addition of ARIA will not automatically enable accessible functionality! It will only convey the intended behavior of that functionality!

For instance, adding the ARIA attribute role=”button” to a div tag will cause screen readers to announce the element as a link, however this div tag will neither be keyboard accessible, nor it will be keyboard actionable. Infallible scripting must be used to ensure proper functionality in all such cases.

So, without any further ado let’s dive into one of the Drag & Drop examples.

Here too, the use of scripting is critical to ensure proper keyboard functionality, while the addition of ARIA will enhance the user experience for screen reader users.

As I understand, for drag and drop it is basically:

1. Tab to move through the list of items
2. Space to select an item
3. Arrow keys to switch between the drop zone(s)
4. Enter to Drop

But, in my opinion, apart from the drag and drop functionalities to be accessible, we need to also provide instruction of how the functionality will work, since it will make life easier for everyone!

It’s like reading a manual before using the actual product!

Some of the Common Patterns for Drag & Drop:

Let’s make ourselves familiar with some common patterns from the mouse users’ perspective. Which can be also made accessible for keyboard users (including screen reader users).

1.      Sorting a List

This is one of the most basic one! The goal of a user here is to change the order from an ordered list of items. They click and hold to grab a list item using a mouse, then move the mouse into a position where they want to drop the list item. Voila! they drop by letting go of the mouse button.

Let’s Structure it!

• Code the elements i.e. Article 1, Article 2, Article 3, etc. as buttons using,
  1. A native <button> element.

OR

1. A custom button using <span> or <div> with role of a ‘button’ along with tabindex value of ‘0’ and scripts for making it accessible using a keyboard as well as mouse.

Tip: Being in an accessibility field, I have learnt a lot but if I must choose between a native and custom, I would always say, go for a native approach. Why make it custom and make everything more complicated?

It now, needs a name!

• Provide the <button> with a descriptive label using,
  1. Place the label text between the <button> element i.e. <button>label text here</button>.

OR

1. An aria-label attribute.

Here, I will be playing with an aria-label attribute between the element.

Next? Yes, a State!

• Using an aria-label to change the value using scripting,

1. When the element is selected, the value should be Article 1 – Selected.
2. When the element is moved to different place, the value should change to Article 1.

Let’s Move the element from one location to another!

• Native <button> with onclick event handler will make it accessible for the keyboard only users as well as screen reader users.
• Use scripting events like onkeypress, onkeydown, onkeyup, onmousedown, onmouseup, to provide the same interaction for a mouse and keyboard.

1. Once the focus is on an element, for e.g. Article 1, press a spacebar key to select an element.
2. Using arrow keys (up or down) move the focus to location, say Article 3.

• Press Enter key to drop the element.
• Once an element is moved from one location to another, provide a visual feedback to the users. Make this alert available for the screen reader users by structuring the message within a <div> element and providing a role of alert to the div as soon as the message is displayed.

For example, provide a message ‘Article 1 has been moved to Article 3, you can continue to move any other article’.

Voila it’s done!

But how can we forget the instructions! Preferable instructions can be found below to be made available at the top.

To move the elements from one place to another,

1. Navigate to the desired element.
2. Press Spacebar key to select the element.
3. Use arrow keys (up or down) to navigate to the position where you want to place the selected element.

2.      Interacting with an Object on a Canvas

This is common in graphical editors, charting and design tools. This type of drag and drop allows the user to place and size an object in their desired position on a 2-dimensional canvas.

Let’s Structure!

Here let’s create an accessible Tic Tac Toe game. We can structure ‘X’ and ‘O’ as image buttons using native <input> element having src value of the ‘X’ and ‘O’ images with an alt attribute of X and O respectively. A spacebar key can be used to select it.

Make it work!

Now, to make this functionality work, an infallible scripting is also required here i.e. scripting events like onkeypress, onkeydown, onkeyup, onmousedown, onmouseup, etc. to make the interaction work. A key event of onkeyup will be fired such that the focus is set automatically to the droppable area using the javascript .setfocus() method as soon as X or O is selected. For keyboard only users, the focus will be set to the first droppable block area. The droppable <div> areas will also require tabindex=”0” value as soon as the draggable element is selected.

Press tab key to navigate through the blocks to place the X or O in the respective block.

Provide the Escape key functionality for users to cancel the entire operation at any time.

The droppable areas need to be identified as well by providing the main <div> container with a role of region and an aria-label having value ‘droppable area for X and O’. For screen reader users, it will be announced as “Region start droppable area for X and O”.

Also, each block which are droppable (<div> areas) can be provided with a visual text to identify the droppable block. For screen reader users provide a hidden text within a <span> element along with an id. A role of region can be used on div and named using an aria-labelledby attribute referencing the id of span for “Block 1” and “Drop Here” text. As soon, as they tab through the blocks, the name will be announced, for e.g. “Region start Block 1 – Drop here”.

To drop the X or O in the respective block, press the Enter key!

Once X or O is placed in the respective block, provide a visual feedback to the users. Make this alert available for the screen reader users by structuring the message within a <div> element and providing a role of alert to the div as soon as the message is displayed.

For example, provide a message ‘X has been moved to Block 1, you can continue to place X or O in desired block again.’

When the action is completed or aborted, clean-up the interface by loading the default values and making the droppable area non-interactive. Also, move the focus to the first draggable element using javascript .focus() method, where the user can start again.

3.     Moving an Item from One List to Another List

Here, a user is presented with several different list of items. The goal here is to move an item between different task. Isn’t that an easy task using a mouse? This is common in Kanban style interface where users change the status of a task by moving an item from one bucket to another. In the image below, the mouse user is dragging Item 1 from “On Hold” task to “In Progress” task.

Ensure items can be reached using a keyboard

Some elements are already reachable using the keyboard alone, such as standard interface elements and buttons. For the elements that do not usually receive focus, you can use the tabindex attribute.

The two useful values: a tabindex attribute value of 0 puts elements in keyboard tab order as they appear in the source; a negative value for the tabindex attribute does not put the element into the keyboard tab order but allows it to receive programmatic focus. If you do not want to clutter the keyboard tab, use a negative tabindex attribute value and control navigation by defining custom keystrokes, for example using the Up and Down cursor keys to navigate through a menu.

A simple demonstration used with this example adds the items in different task such as “On hold”, “Need Review” and so on.

Identify draggable objects

Objects that can be dragged should have their aria-label attribute value as “Item 1 – Press Space to Select” to indicate they are available for dragging but not currently dragged.

It is also important to ensure that interface elements have a visible keyboard focus indicator. Add a focus class when the source objects receive focus. The CSS for the focus class provides an outline to provide a visible focus indicator, in the same way items are highlighted when the mouse is hovered over draggable objects.

Ensure the user can initiate the drag operation with the keyboard

Users must be able to select the elements to drag. The recommended key, Space is used for selection. For the item that is selected, the aria-label attribute value must be “Item 1 – Selected”.

In the example, element is set in response to a mousedown or keydown event.

Identify the drop targets

After an item has been grabbed, valid targets should be identified where the item can be dropped; a class can be used to make the targets visually obvious.

The CSS class simply sets the border along with background color on the list to make it visually evident it is a target.

Ensure drop can be executed using the keyboard

In the example, only one item can be dragged at a time. Here we will be using a context menu that can be activated as soon as the user selects an item using space key to indicate that the item is to take part in a drag and drop operation.

The first stage is to indicate that each item has a popup menu.

objItems[iCounter].setAttribute(‘aria-haspopup’, ‘true’);

The context menu will contain a list of possible target areas (On Hold, Need Review, In Progress, etcetera.) that the user can select using the Up and Down arrow keys.

Cancelling the drag operation

The user should also be able to cancel the drag operation which is recommended key to cancel the operation is the Escape key. Once the operation has been cancelled, all items should be reset to the default values of aria-label attribute. Also, the programmatic focus should be set to the last grabbed source object using javascript .focus() method, when the drag is cancelled.

drag.objCurrent.focus();

Cleaning up after drag and drop operations

As with cancelling the drag operation, after completion of drag and drop activity, the state of all the items along with the label should be set to default. Also, a visual feedback should be provided to the users. Make this alert available for the screen reader users by structuring the message within a <div> element and providing a role of alert to the div as soon as the message is displayed.

For example, provide a message ‘Item 1 has been moved to OnHold task. You can continue moving other items to desired task.’

Hope you find this blog post helpful. These are only some ways of making the drag and drop work! Do provide your comments below if you are familiar with other ways to make a drag and drop work!

The post Can drag and drop be made accessible? Yes! It can be in different ways! appeared first on Leader in Offshore Accessibility Testing | Section 508 Compliance | WCAG Conformance | BarrierBreak.