I have created the Accessibility developer playbook. According to that can you please provide me the checklist for that. Providing below the developer play book content:

Developer Handbook
•	Introduction
o	Brief introduction about Accessibility
o	WCAG
o	Success Criteria’s
o	Conformance Levels
o	How to read this document
•	Knowledge
o	Page structure
o	Images 
o	Forms
o	Semantics
o	Keyboard interaction
o	Interaction
o	Reading Order / Consistency
o	Text Resizing / Responsiveness 
o	Time sensitive
o	Animation
o	WAI-ARIA
o	Media (Audio/Video)
•	Quick tips about Developing Accessible Content in Web
o	Associate a label with every form control
o	When to use a button and when to use an anchor?
o	Include alternative text for images
o	Opening New Windows
o	Identify page language and language changes
o	Use mark-up to convey meaning and structure
o	Help users avoid and correct mistakes
o	Reflect the reading order in the code order
o	Write code that adapts to the user’s technology
o	Provide meaning for non-standard interactive elements
o	Ensure that all interactive elements are keyboard accessible
o	Don’t use ARIA, use native HTML instead
o	Avoid CAPTCHA where possible
•	Custom Elements
o	Accordion
o	Breadcrumb
o	Button
o	Carousel
o	Checkbox
o	Combobox
o	Dialog
o	Disclosure
o	Menubar
o	Menu Button
o	Radio group
o	Tabs
o	Tooltip
•	 Unit testing
o	Using Automated Tools
o	Using Screen readers
o	Text-resize
•	Conclusion












Introduction 
This Developer handbook is an initiative for technology adapted to people with disabilities. The vision behind the Accessibility Developer Guide is to bridge the gap between providers of websites and users with special needs.
The Accessibility Developer Guide is a comprehensive tutorial for learning accessibility, as well as a quick reference for your daily development business.
Brief introduction about Accessibility
Accessibility entails the inclusive practice of eliminating obstacles that would impede access. This is achieved by structuring content so that individuals of varying abilities can easily navigate it, for instance, by labeling document headings or adding captions to videos. Specifically, web accessibility focuses on overcoming challenges that hinder access to digital platform information.	
WCAG 
WCAG provides a common definition for accessible content, a benchmark. Web "content" is the information in a web page, Web site, or web application, including natural information such as text, images, and sounds. code or markup that defines structure, presentation, etc.
Web Content Accessibility Guidelines (WCAG) 2.2 defines how to make Web content more accessible to people with disabilities. Accessibility involves a wide range of disabilities, including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities.
 
Success Criteria’s
Success Criteria address a situation where a user with a disability will be disproportionately disadvantaged (as compared to a user without a disability) if the criteria is not met. They must be testable through automated or manual processes.
Conformance Levels
Conformance to a standard means that you meet or satisfy the 'requirements' of the standard. In WCAG 2.0 the 'requirements' are the Success Criteria. To conform to WCAG 2.0, you need to satisfy the Success Criteria, that is, there is no content which violates the Success Criteria.
•	Level A: For Level A conformance (the minimum level of conformance), the Web page satisfies all the Level A Success Criteria, or a conforming alternate version is provided.
•	Level AA: For Level AA conformance, the Web page satisfies all the Level A and Level AA Success Criteria, or a Level AA conforming alternate version is provided.
•	Level AAA: For Level AAA conformance, the Web page satisfies all the Level A, Level AA and Level AAA Success Criteria, or a Level AAA conforming alternate version is provided.
 

How to read this document
This guide aims to provide a comprehensive resource for both beginners looking for a pragmatic way to dive into the world of accessibility, as well as seasoned experts wanting to extend their knowledge and embrace new inspirations. Here you will find out how to read through our guide, and how to stay up to date.
This guide encompasses a huge amount of knowledge about various topics of both theoretical and practical nature, all of which are highly relevant to developing accessible websites.
The main audience are web developers, but testing staff, content editors, project managers, etc. may also benefit from it.
To get the most out of this guide, let us explain to you how to use it best, and how you can contribute to it.

Knowledge 
Knowledge about Accessibility
To begin developing accessible websites, some basic knowledge about the required tools and techniques is needed. The upcoming sections will help you to get acquainted with various important topics of a rather theoretical nature - with high practical value though. It will prepare you to actively dive into the world of accessible website development.

Page Structure Tutorial
Well-structured content allows more efficient navigation and processing. Use HTML and WAI-ARIA to improve navigation and orientation on web pages and in applications.
•	Page Regions: Identify and mark up regions on web pages using HTML5 and WAI-ARIA roles.
 
•	Labeling Regions: Label regions to allow users to distinguish and access them.
 
•	Headings: Add headings and nest them logically to label sections of web pages according to their relationships and importance.
 
•	Content Structure: Mark up the content on a page in a way that uses appropriate and meaningful elements.
 
•	Page Title: Each page should have a clear and descriptive title that appears in the page’s <head> and is visible in the browser’s tab.
 
•	Page Language: Identify the page’s language in the <head> to help browsers and assistive technologies present the content correctly. 
Images Tutorial
Images must have text alternatives that describe the information or function represented by them. This ensures that images can be used by people with various disabilities. This tutorial demonstrates how to provide appropriate text alternatives based on the purpose of the image:
•	Informative images: Images that graphically represent concepts and information, typically pictures, photos, and illustrations. The text alternative should be at least a short description conveying the essential information presented by the image.
 
•	Decorative images: Provide a null text alternative (alt="") when the only purpose of an image is to add visual decoration to the page, rather than to convey information that is important to understanding the page.
 
•	Functional images: The text alternative of an image used as a link or as a button should describe the functionality of the link or button rather than the visual image. Examples of such images are a printer icon to represent the print function or a button to submit a form.
•	Images of text: Readable text is sometimes presented within an image. If the image is not a logo, avoid text in images. However, if images of text are used, the text alternative should contain the same words as in the image.
 
•	Complex images such as graphs and diagrams: To convey data or detailed information, provide a complete text equivalent of the data or information provided in the image as the text alternative.
•	Groups of images: If multiple images convey a single piece of information, the text alternative for one image should convey the information for the entire group.
•	Image maps: The text alternative for an image that contains multiple clickable areas should provide an overall context for the set of links. Also, each individually clickable area should have alternative text that describes the purpose or destination of the link.
 
For a quick overview on deciding which category a particular image fits into, see the alt Decision Tree. The text alternative needs to be determined by the author, depending on the usage, context, and content of an image. For example, the exact type and look of a bird in an image might be less relevant and described only briefly on a website about parks but may be appropriate on a website specifically about birds.
Forms Tutorial
Forms are commonly used to provide user interaction on websites and in web applications. For example, login, registering, commenting, and purchasing. This tutorial shows you how to create accessible forms. The same concepts apply to all forms, whether they are processed client or server-side.
Aside from technical considerations, users usually prefer simple and short forms. Only ask users to enter what is required to complete the transaction or process; if irrelevant or excessive data is requested, users are more likely to abandon the form.
•	Labeling Controls: Use the <label> element, and, in specific cases, other mechanisms (e.g. WAI-ARIA, title attribute etc.), to identify each form control.
 
•	Grouping Controls: Use the <fieldset> and <legend> elements to group and associate related form controls.
 
•	Form Instructions: Provide instructions to help users understand how to complete the form and individual form controls.
 
•	Validating Input: Validate input provided by the user and provide options to undo changes and confirm data entry.
 
•	User Notifications: Notify users about successful task completion, any errors, and provide instructions to help them correct mistakes.
 
•	Multi-Page Forms: Divide long forms into multiple smaller forms that constitute a series of logical steps or stages and inform users about their progress.
 
•	Custom Controls: Use stylized form elements and other progressive enhancement techniques to provide custom controls.

Semantics
While today's trend goes for more and more fancy visuals everywhere, it is still important to markup content with proper HTML. In this chapter, you will get familiar with the concept of "semantics", and why they are indispensable in website development.
Semantics provide meaning
Not surprisingly, HTML (Hyper Text Markup Language) is exactly that: a markup language. This means that it is not only plain text, but text marked up with meaning - so-called "semantics". For this, HTML offers a lot of tags, each with an inherent, unique semantic meaning. And those tags must be used properly.
Tags with no meaning
To understand the importance of proper semantics, let's first look at the exceptions: tags that indeed do not provide semantical information.
There are only two tags in HTML that do not have any semantic meaning: <div> and <span>. Their purpose is to offer containers needed for visual styling. And their only difference is that <div> is a block element, while <span> is an inline element.
Example: -
<div> My hobbies </div>
<div> Dancing </div> 
<div> Playing soccer </div>
Tags with meaning
•	Content elements are used to give meaning to content (like headings, paragraphs, or links).
Example: - 
<h1> My hobbies </h1>
<h2> Dancing </h2>
<h2> Playing soccer </h2>
Marking up text using an <h#> tag tells the user agent that this is not just plain text, but - in fact - a heading of a certain level!
•	Structural elements are used to group elements on a webpage, separating them into different regions (like header, navigation, main, or footer). They have been introduced in HTML 5.
Example: - 
<header> 
<! -- Content like logo, link to start page, etc. --> </header> 
<main> 
<h1> My hobbies </h1>
 <h2> Dancing </h2> 
<h2> Playing soccer </h2> 
</main> 
<footer> <! -- Content like disclaimer, contact info, etc. --> </footer>
 
Keyboard Interactions
Due to physical restrictions, many users cannot control a pointing device like a mouse or touch screen. So, they rely on keyboard usage only, and thus, software must be fully functional with a keyboard only. This does not only benefit disabled users, but also power users.
Keyboard only navigation
Even for users who are not able to control a common keyboard, there are various special input devices. Sometimes called "switches", they are tailored to the needs of different user groups. The complexity of these devices varies a lot, some of them having only a few buttons. But in general, they are "mimicking" default keyboards and offer similar interaction opportunities.
So, by making sure that your websites are controllable with a default keyboard, many other special input devices are automatically taken care of.
Browse websites using a keyboard only
Browsing a website (which means opening it, reading its content and interacting with the available controls) using a keyboard only is delightfully easy. Browsers offer all this functionality with only a few keys on the keyboard.
Interacting with a website
Mouse users can interact with any visible element on a page directly by clicking on it.
To interact with an element, keyboard users need to move the so-called "focus" sequentially through all interactive elements on a page until they reach the desired element. The currently focused element is highlighted visually.
•	Use Tab to move from one focusable item to the next focusable item.
o	This sequential navigation sometimes is called "tabbing".
o	Focusable items typically are links, buttons, form controls (text edit, combo box, etc.), and all sorts of other interactive elements such as custom widgets.
o	Add Shift to reverse the direction.
•	Use Enter to:
o	Activate a link or button.
•	Send a form (when a form item has focus).
o	Works for all form elements except textarea.
•	Use Space to:
o	Toggle an element's state (for example checkbox).
o	Open or close an element (for example combobox).
•	Use arrow keys to:
o	Change the value of an item (for example in a combo box, a radio button group, or within a min/max value slider widget).
o	Move the cursor (for example in a text input).
•	Use Esc to:
o	Cancel a prompt.
o	Close elements like dialogs or expanded combo boxes.

 
Implementing websites for keyboard only usage
Standard functionality
As HTML is fully keyboard-only accessible, all standard HTML controls offer built-in support for keyboard interaction. This is provided by the browser. Recommend sticking to using proper semantic HTML markup.
Custom functionality
If you need to provide custom functionality on your website (for example a fancy JavaScript widget that does not have an HTML equivalent), recommend optimizing it specifically for keyboard interaction.
Focusability
Ensure any relevant element is focusable by keyboard:
•	Either by using an HTML element that inherently is focusable (for example a link or a button).
o	Whenever an element should be interacted with, this is the proper way to go.
•	Or by adding the tabindex="0" attribute, for example <div tabindex="0">
o	This should only be used in situations when an element shall be focusable, but not interactive (a very rare case).
•	A special case is <a> tags: if they have an href attribute, they are focusable; otherwise, in most browsers, they are not.
 

Keyboard operability
Implement any functionality as needed by adding appropriate events, for example, onclick or similar:
•	Be sure to use browser-independent events.
o	An onclick event is triggered by all sorts of devices (regardless of whether it's fired upon a mouse click or by pressing a keyboard's Enter key).
•	On the other side, a hover event can only be triggered by some devices (for example mouse) and not by others (for example keyboard)
o	A well-known accessibility problem is dropdown menus opening on hover only, so no keyboard user will ever be able to open it.
•	Avoid listening to specific keyboard keys, unless you want to provide device-specific functionality.
•	For example, listening to a keypress event and looking for a key code 13 (Enter key) will only catch a real keyboard's Enter key.
	But it won't catch a screen reader's Enter key, as pressing Enter with a screen reader running will typically fire a click event instead.
o	As described above, it's usually better to listen to a click event here.
•	Be aware that many keys are only available on full-fledged keyboards of desktop computers.
	Be sure not to bind functionality to such specific keys (for example modifier keys like Alt) or provide alternative ways to use the functionality.
	Even arrow keys aren't available on many devices, for example touch screen smartphones.
o	Especially combinations of keys can be hard (if not impossible) to be pressed by motor-impaired people.

Standards over custom
Recommended to always look for a standard behavior first that may fit your need (even if it looks very different at first sight).
Focus management
Another facet of keyboard optimization is setting the focus properly if needed.
Setting focus to an element
For example, when a user clicks on a button "Show terms and conditions (dialog)", then the keyboard focus must be set into the dialog properly. Otherwise, the keyboard focus usually is hidden somewhere "behind" the dialog. If users then want to interact with the dialog (be it filling out some displayed form elements, clicking a link within its content, or simply pressing its close button), they are forced to press Tab again and again until the focus suddenly appears in the dialog.

Specifically, the first content element of the dialog should be focused, due to the following reason: users usually make their way from top to bottom of a page, be it while reading content or moving the keyboard focus. Placing the focus on the first content element does not interrupt this workflow.

Avoiding focus on background elements
Dialogs typically are placed on top of the page's other content, often darkening the background. As explained above, keeping the focus placed in the background after opening a dialog is nasty for keyboard users. So, we should take care that this does not happen by accident again when the user is interacting with the dialog.

One common practice is to trap the focus within the dialog: this means that after the last focusable element of the dialog loses focus, the first element is focused again. This way, if users have interacted with the form and then want to close it again using the close button on top of the dialog, they do not have to tab back to the top (using Shift + Tab), but intuitively reach the close button again automatically.

But there is a big disadvantage with this technique: users will not be able at all to leave the page content using the Tab key, A better solution is to not trap the focus but to offer another close button at the bottom of the dialog. This way, the user won't need any more to press Tab again, in the hope of reaching the close button at the top.

Resetting focus
As soon as the user closes the dialog, the focus needs to be set back to the element it initially had before opening the dialog. In our example, this was the "Show terms and conditions (dialog)" button. Otherwise, the focus gets "lost", and it is automatically set by the browser to the very beginning of the page.

Be careful with setting focus
Only set focus if it clearly is not feasible to leave it where it currently is.
Interaction
There are many ways in which a user can interact with a device, and various methods better suit users with different needs. Users will have a predefined knowledge and expectation of how software should work. Good interaction design is intuitive, clear, and predictable, with no cognitive burden on the user.
No context changes on input
When a user inputs information or interacts with a control, the page should not cause a change in page content, spawn a new browser window, submit a form, case further change in focus, or cause any other change that disorients the user. If an input causes such a change, the user must be informed ahead of time.
No context changes on focus
When the focus changes, the page should not cause a change in page content, spawn a new browser window, submit a form, case further change in focus, or cause any other change that disorients the user.
 
Content on hover/focus
•	To the extent possible, content that appears on hover or focus should not obscure other content, unless it presents a form input error. or can be dismissed with the escape key.
•	For tooltips, follow corresponding ARIA authoring practice.
•	For content that appears on hover and focus: the content should be dismissible with the escape key; the content itself can be hovered over; and the content remains available unless it is dismissed, it is no longer relevant, or the user removes hover and focus.
 
Shortcut keys
If a keyboard shortcut uses only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then the user must be able to disable the shortcut, remap the shortcut, or limit the shortcut to only when a particular interactive element has focus.
Pointer cancellation
•	Recommend avoiding triggering functionality on down-events, such as onmousedown. Use events such as onclick instead.
•	If a function is triggered on an up-event (e.g. onmouseup), provide a way to abort or undo the function.
 
Pointer gestures
Do not require multipoint or path-based gestures (e.g. pinching, swiping, dragging) for functionality unless the gesture is essential to the functionality.
 
Motion actuation
Avoid activating functionality through motion (e.g. shaking a phone). If motion triggers functionality, provide a way to disable the motion trigger, and provide an alternative way to activate the functionality.
 
Dragging movements
The technique's objective is to ensure that people with motor impairments who cannot carry out dragging movements are presented with an alternative single-pointer interaction that does not involve dragging.
•	Make sure there’s an alternative single pointer input available that serves the purpose of the dragging function. One option could be a series of single pointer interactions, such as opening a dropdown menu. 
•	Create keyboard equivalents for the same function as a dragging movement, for example “u” for up, “d” for down, “t” for top, and “b” for bottom.
•	Another alternative to dragging could be providing a context-sensitive menu from which the user can move the item up one row, down one row, to the top, or to the bottom.
 
Target size
The technique's objective is to help ensure targets can be easily activated without accidentally activating an adjacent target. Users with dexterity limitations and those who have difficulty with fine motor movement find it difficult to accurately activate small targets when there are other targets that are too close. Providing sufficient size, or sufficient spacing between targets, will reduce the likelihood of accidentally activating the wrong control.
•	Ensuring that targets are big enough and that there’s sufficient space between them makes it less likely that a user will accidentally activate the wrong control. 
•	Meeting this success criterion will make your website more accessible for people who may have difficulty with fine motor control movements and even people with large fingers. 
•	There are several exceptions to the 24×24 CSS pixels of space requirement. For example, if the offset of the spacing is at least 24 CSS pixels, then a target can be smaller than 24×24.
 
Reading Order
The importance of maintaining a logical and intuitive accessibility reading order cannot be overstated. It is essential to ensure that all users, particularly those with visual impairments or cognitive disabilities, can understand and navigate content effectively. 
Here’s why it’s so crucial:
•	User Experience: A logical reading order provides a coherent and meaningful experience, allowing users to follow the content as intended.
•	Screen Readers: Assistive technologies like screen readers rely on the established reading order to accurately narrate content to users with visual impairments.
•	Comprehension: The reading order can significantly affect the comprehension of the content. Disorganized content can lead to confusion and misinterpretation.
•	Accessibility Compliance: Adhering to a logical reading order is a key component of accessibility standards like the Web Content Accessibility Guidelines (WCAG), which aim to make web content more accessible to a wider range of people with disabilities.
•	Inclusivity: By prioritizing accessibility reading order, content creators contribute to creating a digital environment where information is accessible to users of all abilities, fostering an inclusive society.

In summary, the reading order is a fundamental aspect of document accessibility that ensures content is accessible to everyone, enhancing the overall user experience and promoting inclusivity. It’s not just best practice; it’s a necessity for creating content that is truly accessible to all.
Ways to achieve correct reading order 
•	DOM Order: Align the reading order with the order of elements in the Document Object Model (DOM). This ensures that screen readers follow the visual flow of the page.
•	Semantic HTML: Use semantic HTML tags to structure content. This helps convey the meaning and structure of web content to assistive technologies.
•	CSS Layout: Be cautious with CSS positioning as it can affect the reading order. Use CSS layout techniques that maintain a logical sequence of content.
•	Interactive Elements: Ensure that interactive elements like forms, buttons, and links are ordered logically within the navigation flow.
•	Hidden Content: Content that is visually hidden or inactive should also be hidden from screen reader users until it is made visible and active.
•	WAI-ARIA: Use WAI-ARIA roles and properties to enhance the semantics of elements where native HTML does not suffice, especially for complex UI controls.
•	Testing: Regularly test your website with screen readers and other assistive technologies to ensure the reading order is consistent with the visual order.
 
Text Resizing / Responsiveness
Text resizing and responsiveness are critical aspects of web accessibility, ensuring that content is usable and legible for all users, including those with visual impairments or disabilities. 

Here’s why they are important:
•	Usability Across Devices: Responsive design allows content to adapt to various screen sizes, making it accessible on desktops, tablets, and smartphones.
•	Low Vision Support: Users with low vision can resize text up to 200% without loss of content or functionality, as per WCAG 2.0 guidelines. This is essential for readability without the need for assistive technologies like screen magnifiers.
•	User Control: Allowing users to adjust text size according to their preferences gives them control over their reading experience, which can be crucial for those with specific visual needs.
•	Reflow of Content: When text is resized, the content must reflow accordingly to prevent loss of information or functionality. This ensures that enlarging text does not result in text spilling off-screen or overlapping with other content.
•	Cognitive Accessibility: Some users with cognitive disabilities benefit from larger text for better comprehension and ease of reading.
•	Avoidance of Horizontal Scrolling: Properly implemented text resizing ensures that users don’t have to scroll horizontally to read each line, which can be a significant barrier to accessibility.
•	Compliance and Inclusivity: Adhering to text resizing and responsiveness standards is not only about compliance with accessibility laws and guidelines but also about inclusivity, ensuring that digital content is accessible to as wide an audience as possible.

In summary, text resizing and responsiveness are not just about accommodating users with disabilities; they’re about creating a flexible and user-friendly web environment that benefits all users. It’s a fundamental aspect of designing for inclusivity and ensuring equal access to information and services online.
Here are some guidelines for developers:
•	Use Relative Units: Employ relative units like percentages, ems, or rems for font sizes, padding, and margins to ensure scalability and responsiveness.
•	Viewport Units: Consider using viewport units (vw, vh, vmin, vmax) for more fluid responsiveness, especially for large headings or call-to-action buttons.
•	Media Queries: Utilize CSS media queries to adjust text sizes and layout based on the screen size and resolution.
•	Min and Max Size: Define minimum and maximum font sizes to ensure legibility across devices.
•	Flexible Containers: Design containers to be flexible so that they can adjust to the text size without breaking the layout.
•	Testing: Test your website’s text resizing and responsiveness across different devices and browsers to ensure a consistent user experience.
•	Accessibility Tools: Use accessibility tools and browser extensions to simulate text resizing and ensure that your design maintains its integrity at different scales.
•	Avoid Fixed Units: Steer clear of fixed units like pixels for font sizes as they can hinder the user’s ability to resize text.
•	Font Loading: Ensure that fonts are loaded efficiently to prevent layout shifts when text is resized.
•	Content Prioritization: Prioritize content to ensure that the most important information remains prominent and readable at all sizes.

 
Time Sensitive
If a page or application has a time limit, the user MUST be given options to turn off, adjust, or extend that time limit.
Meaning:
•	The user must be able to extend the session with the use of a keyboard.
•	The user must be allowed 20 seconds or more to extend the session with a single simple action (Ex: spacebar keypress) and must be given the ability to extend the time limit no less than 10 times.
•	Users must be warned before the time-out is reached through a textual notification - generally a modal window.
•	The mechanism (i.e. Modal) must be visually accessible with a mouse, function and gain immediate focus with a keyboard and screen reader and allow for the extended time to be selected.
Implementation:
Give a user at least 90 seconds (about 1 and a half minutes) to select a timeout warning message.
 

Animation
Animation is used in digital products in many ways, such as drawing a user’s focus to a particular area on the screen, providing another layer to a brand’s style with unique and ownable motion design, and adding a spark of unexpected fun to an otherwise robotic interaction.
But designing animation that surprises and delights accessibly is trickier than it sounds.
Dizziness, nausea, disorientation, migraines, and even seizures can all be caused by well-executed yet inaccessible motion design. Because of this, it is critical to design your animation with both aesthetics and accessibility in mind.
1.	Allow users to pause, stop, or hide moving content
While most web animation durations fall well below the five-second limit, some last longer than five seconds. These include slideshows, auto-advancing carousels, and animated illustrations and backgrounds. 
In such cases, provide stop-and-play controls that let users manage the motion and any auto-playing pattern. Doing so helps users with vision-related disabilities, attention-related disorders, and certain neurocognitive conditions.
 
2.	Avoid flashing content
Users with photosensitivity may experience seizures when flashing content appears frequently. That is why the WCAG 2.3.1 (Three Flashes or Below Threshold) success criterion mandates that: 
‘Web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds.’
The guideline also gives information on the size, ratio, and viewing angle thresholds that help to determine if flashing the screen is safe. However, it’s probably the best practice to totally avoid all flashing content. 
Still, if you must use flashing animations in your content, give users advance notice about it. Also, provide an alternative version of the content without the flashing effect.
One more thing, WCAG 2.3.1 is a Level A requirement. That means your website is not reasonably accessible if it fails to meet this success criterion.
 
3.	Avoid unnecessary animations 
Motion-based animations are two-edged – they could improve engagement, but some users may find them distracting. The best practice here is to avoid them or provide an animation-free alternative. 
Here, it is essential to take context and expectations into serious consideration. For instance, you’d expect to see more motion animation on an educational or video game website than on a government or health website.
4.	Provide options for users to turn off motion animation 
The WCAG 2.3.3 success criterion expressly states that: 
‘Motion animation triggered by interaction can be disabled, unless the animation is essential to the functionality, or the information being conveyed.’
Essentially, if your website contains content that could disturb motion-sensitive users, provide options to turn it off. Alternatively, you could offer a scaled-down version of the animation. Such options could be a toggle or preference-setting that, when engaged, allows users to indicate their choice for reduced motion.
 
5.	Provide reduced-motion feature
Sometimes, a custom toggle may not be the best approach for websites or mobile applications that don’t rely much on rapid movement. Instead, they can use the prefers-reduced-motion media query on its own.
The feature allows them to offer a condensed version of heavily animated content when the user’s operating system makes that preference available globally.
Additionally, users can configure it in one location to affect several contents they come across. That makes it a great tool to effectively recognize and respond to a user’s desire for reduced motion.
WAI-ARIA
There are indeed situations where standard HTML does not provide functionalities for all the requirements developers may have for implementing modern and interactive websites. For this, the Accessible Rich Internet Applications (ARIA) technical specification was introduced. 
ARIA, which stands for Accessible Rich Internet Applications, refers to a set of more than 150 declarations that can be added into web page code so assistive technologies, such as screen readers, can understand how to present the page. For example, the text "Home" might be visually presented as a heading, an interactive link or button, or as the label for a phone number. If the web code does not declare what the element containing that text represents, a screen reader cannot present it to a blind user in an accessible way.
The declarations that can be made with ARIA are defined by the WAI-ARIA Specification. These attributes and other features required to make sites usable by people who rely on assistive technologies or keyboard navigation are not natively included in the languages used to create web sites, such as HTML, JavaScript, CSS, and SVG.
Purpose
When it comes to requirements of modern interactive websites, sometimes the semantic vocabulary of HTML may not be enough anymore. To fill this gap, the Accessible Rich Internet Application (ARIA) specification was introduced: it describes how to add semantics to HTML content to make user controls and dynamic content more accessible.
Accessibility semantics
Accessibility semantics refers to the meaning of user interface elements that need to be conveyed to assistive technology users for them to understand and use the elements. For example, people who can visually perceive a search icon button understand the element can be activated to perform a search by the way it is styled and positioned. To make that icon accessible to a screen reader user, one of the semantics that needs to be communicated is that the element represents an interactive button. This is accomplished by encoding the element in a way that enables browsers to determine that the accessibility role of the element is button. Similarly, another accessibility semantic browsers must be able to convey for the search icon is its accessible name, which in turn enables screen reader users to know the purpose of the button.
The types of accessibility semantics that may be required to make an element accessible include:
•	Role: The type of element, e.g., button or list. ARIA includes more than 80 roles that can be declared in content.
•	Properties: Attributes that provide information about the nature of an element, such as its name, orientation, or position in a set.
•	State: A dynamic property, such as selected, checked, or disabled, whose value may be changed by users or application events.

Bad ARIA practices
There are certain situations where ARIA is a good (and maybe the only) way to go. But if done wrong, usage of ARIA often leads to even worse accessibility. ARIA is often misunderstood as "general repair kit" for accessibility problems. Developers new to accessibility usually think that ARIA can be used to fix accessibility problems for all sorts of bad HTML code. In general, though, throwing some ARIA attributes into the mix of bad semantics does not leverage any problem.
ARIA is not meant to be used to "fix" standard elements that lack semantical meaning. So, remember using ARIA to add missing semantical information is never a good solution. Always use the proper HTML tag itself!
We also sometimes see overzealous developers adding redundant ARIA roles to elements, thinking it would enhance accessibility. Example: <form role=”form”>...</form> It does not - quite the contrary is often the case, as screen readers seem to behave buggy from stuff like this.
ARIA offers ways to label elements, for example aria-label. This means adding text to (or sometimes changing an existing text of) an element. This label is then announced by screen readers. Alas, it may be tempting to add such labels to all elements on a page that are missing descriptive text themselves.
Approach using visually hidden text: Again, there are traditional techniques to achieve the wanted result that are much more robust. In the case of our example, simply add a real text label, and hide it visually:
<a class="cart">
  <span class="visually-hidden">Shopping cart</span>
</a>
 

Media (Audio / Video)
Media accessibility, particularly for video and audio content, is the practice of making media accessible to people with disabilities, including those who are deaf, hard of hearing, blind, or visually impaired and thus ensuring that everyone can access and understand the content. 
User Needs: 
It’s important to consider how people with different access needs will use media content. Making your audio and video content accessible can benefit users with and without a disability. For example, any user may choose to quickly read through a transcript instead of watching a video. Or they might use captions in loud locations where the audio can’t be heard or in quiet environments where sound can’t be used. Captions can also be helpful to people who are not native speakers of the language.
The basics: 
Begin with the following things to start making your video or audio content accessible:
•	provide a transcript
•	use captions for video
•	provide an audio description for video that includes important visual information
•	make it clear where to find the transcript and audio-described version
•	use a media player that meets accessibility considerations such as keyboard accessibility
Examples of users with access needs:
User	Access need	May find helpful
Cognitive impairment	Difficulty processing auditory information	Captions
Deaf or has a hearing impairment	Cannot hear the audio	Captions or a transcript
Blind or partially sighted	Cannot see the visual elements of a video	•	Text-to-speech software to read a transcript
•	Audio description to describe video content
Deafblind	Cannot hear audio or see the visual elements	Transcript, which can be converted to braille
Motor impaired	Cannot use a mouse	Media player that can be controlled using keyboard or voice input
Creating good content:
Your video and audio content needs to be as accessible as possible, even before you provide alternatives such as captions and a transcript to ensure everyone has a comparable experience.
The video and audio itself:
When creating the video and audio consider the following.
Do:
•	make sure speech can be clearly heard and there’s good separation from any background noise
•	make sure information makes sense to people who cannot see the video by being as descriptive as possible in the main audio
•	add audio description to convey information that cannot be included in the main audio
•	try to have the speaker in frame
•	allow space for a sign language interpreter
•	make sure text is easy to read and has good color contrast
Do not:
•	use jargon, acronyms or idioms
•	use flashing content as this may cause seizures
Captions:
You should always provide captions that are synchronized with the audio. Captions are the audio in text form, displayed on the video screen.
When creating captions, make sure you:
•	make it clear who’s speaking
•	include important sounds as well as speech
•	check them for accuracy if you’re auto-generating them
•	use closed captions when the video player supports this
Closed and open captions:
Use closed captions rather than open captions. Closed captions can be hidden or shown by the user.
 
Transcript:
Provide a transcript for all media content. A transcript is the text of all the content in a video, presented separately from it.
Make sure you:
•	include all the audio and visual information so that users can understand all the content that’s in the video just from the transcript
•	position the transcript next to the video or clearly link to it
•	create a transcript that’s accessible
Audio description:
An audio description describes visual information needed to understand the content of a video.
Make sure you:
•	make it clear where to find the audio-described version (if separate from the main video content)
•	include all the audio and visual information in the video so that you could understand all the content
Alternatively, if your video is narrated, you could incorporate any important visual information into the narration.
Media player accessibility:
In addition to making the content accessible, the video or audio player must also be fully accessible:
•	do not autoplay video or audio content
•	ensure that the media player meets all other accessibility considerations, such as keyboard accessibility
Sign language:
Provide sign language interpretation for video that has audio content - when you have identified a need.


Quick tips about Developing Accessible Content in Web

This introduces some basic considerations to help you get started developing web content that is more accessible to people with disabilities. These tips are good practice to help you meet Web Content Accessibility Guidelines (WCAG) requirements.

Contents
•	Associate a label with every form control
•	When to use a button and when to use an anchor?
•	Include alternative text for images
•	Opening New Windows
•	Identify page language and language changes
•	Use mark-up to convey meaning and structure
•	Help users avoid and correct mistakes
•	Reflect the reading order in the code order
•	Write code that adapts to the user’s technology
•	Provide meaning for non-standard interactive elements
•	Ensure that all interactive elements are keyboard accessible
•	Don’t use ARIA, use native HTML instead
•	Avoid CAPTCHA where possible

Associate a label with every form control
Use a for attribute on the <label> element linked to the id attribute of the form element or use WAI-ARIA attributes. In specific situations it may be acceptable to hide <label> elements visually, but in most cases, labels are needed to help all readers understand the required input.

Example: Using for and id attributes
Rendered
Username   


Code Snippet
<label for="username">Username</label>
<input id="username" type="text" name="username">

The advice below will boil down to this:
1. Have visible labels (don't rely on only using placeholder text)
2. Visibly associate labels with the field to which they relate
3. Use icons and text together (not icons in isolation) in labels
4. Ensure the label is super clear about what needs to be input into the field
5. Add extra information if a specific format is expected


When to use a button and when to use an anchor?
There are two primary elements we can use for an action – a button (<button> or <input type=button>) or an anchor (<a>).
Anchors
An anchor is used to either link to another URL, or link to an element from another page or within the same page (a "named" anchor). For example:
Code Snippet
<a href="page1.html">Another page</a>
<a href="page1.html#element">An element with an ID of "element" or an anchor with a name of "element"</a>
<a href="#element">An element with an ID of "element" or an anchor with a name of "element"</a>

Button
A button is used for another arbitrary action, such as switching to grid view or zooming in on an image. For example:
Code Snippet
<button>Arbitrary action</button>
If replacing the anchor as is not possible, then add role="button" to expose the new semantics to assistive technologies and change the keyboard interactions (i.e. it should be activated using both Enter and Space keys) using JavaScript.
Code Snippet
<an id="page2" href="page2.html" role=”button”>Link behavior</a>

Include alternative text for images
Ensure that alternative text for images is added to all informational and functional images. Use empty alternative text, alt="" for decorative images, or include them in the CSS instead. Text alternatives are usually provided by those responsible for written content.

Opening New Windows
The general recommendation about new windows, is not to open them. The behavior can be jarring and confusing to the user or have unexpected results (such as opening in a tab rather than a new window).
However, there are some scenarios where a new window can be useful. For example, opening a chat window that exists alongside your existing window, so that you can continue to use the site whilst speaking to a support expert can be a great and beneficial user experience. In these instances, there are important rules to follow:
New windows must not be opened without prior warning
Give users advanced warning when opening a window. This can be done via visible text stating "(opens in new window)" as part of the link, or with an icon with an appropriate alt attribute such as this one:
Note: Do not use the "title" attribute for this purpose, since it cannot be perceived by many Assistive Technologies.
New windows must not be opened without the users' consent
Do not open new windows when a page is loading or when selecting radio buttons or checkboxes. The user must be aware that a new window will open, and consciously approve this behavior.
The "target" attribute must be used on links that open new windows
target="_blank" should be used on links that open new windows. 

Identify page language and language changes
Indicate the primary language of every page by using the lang attribute in the html tag, for example <html lang="en">. Use the lang attribute on specific elements when the element's language differs from the rest of the page.

Use mark-up to convey meaning and structure
Use appropriate mark-up for headings, lists, tables, etc. HTML5 provides additional elements, such as <nav> and <aside>, to better structure your content. WAI-ARIA roles can provide additional meaning, for example, using role="search" to identify search functionality. Work with designers and content writers to agree on meanings and then use them consistently.
Example: Using HTML to provide structure and meaning

Rendered (screen shot)
 

Code Snippet
<section>
  <article>
    <h2>Superbear saves the day</h2>
    <time datetime="2015-08-07">7 Aug 2015</time>
    <p>The city's favorite bear yet again proves his mettle by rescuing a young cat from a tree. Witnesses say that Superbear's efforts were not appreciated by the feline, who inflicted some minor scratch wounds on his rescuer.</p>
    <aside>
      <h3>Related Articles</h3>
      <ul>
        <li><a href="#">Bear receives key to city</a></li>
        <li><a href="#">Superbear stands for mayor</a></li>
      </ul>
    </aside>
  </article>
</section>

Example: Search field using WAI-ARIA
Rendered (Screen shot)
 

Code Snippet
<form action="#" method="post">
  <div role="search">
    <label for="search">Search for</label>
    <input type="search" id="search" aria-describedby="search-help">
    <div id="search-help">Search records by customer id or name</div>
    <button type="submit">Go</button>
  </div>
</form>

Help users avoid and correct mistakes
Provide clear instructions, error messages, and notifications to help users complete forms on your site. When an error occurs:
•	Help users find where the problem is
•	Provide specific, understandable explanations
•	Suggest corrections
Be as forgiving of format as possible when processing user input. For example, accept phone numbers that include spaces and delete the spaces as needed.

Example: Australian phone number field with forgiving validation
Rendered (Screen shot)
 
Code Snippet
<label for="phone">Phone</label>
<input id="phone" name="phone" type="tel"
       pattern="^(\(?0[1-9]{1}\)?)?[0-9 -]*$"
       aria-describedby="phone-desc">
<p id="phone-desc">For example, (02) 1234 1234</p>

Reflect the reading order in the code order
Ensure that the order of elements in the code matches the logical order of the information presented. One way to check this is to remove CSS styling and review that the order of the content makes sense.
Example: Reflecting the logical reading order in the code

 

Image before heading may be missed   
<img src="images/trainer.png" alt="...">
<h3>Space trainers</h3>
<p>Space...</p>
<a href="...">Add to cart</a>

Heading marks the start of the section   
<h3>Space trainers</h3>
<img src="images/trainer.png" alt="...">
<p>Space...</p>
<a href="...">Add to cart</a>

Write code that adapts to the user’s technology
Use responsive design to adapt the display to different zoom states and viewport sizes, such as on mobile devices and tablets. When font size is increased by at least 200%, avoid horizontal scrolling and prevent any clipping of content. Use progressive enhancement to help ensure that core functionality and content is available regardless of technology being used.
Example: Using media queries to adapt navigation

/* On narrow viewports, make the navigation full width */
@media screen and (min-width: 25em) {
  #nav {
    float: none;
    width: auto;
  }
  #main {
    margin-left: 0;
  }
}

/* On wider viewports, put the navigation on the left */
@media screen and (min-width: 43em) {
  #nav {
    float: left;
    width: 24%;
  }
  #main {
    margin-left: 27%;
  }
}

Provide meaning for non-standard interactive elements
Use WAI-ARIA to provide information on function and state for custom widgets, such as accordions and custom-made buttons. For example, role="navigation" and aria-expanded="true". Additional code is required to implement the behavior of such widgets, such as expanding and collapsing content or how the widget responds to keyboard events.

Example: Menu function and state identified using WAI-ARIA
<nav aria-label="Main Navigation" role="navigation">
  <ul>
    <li><a href="...">Home</a></li>
    <li><a href="...">Shop</a></li>
    <li class="has-submenu">
      <a aria-expanded="false" aria-haspopup="true" href="...">SpaceBears</a>
      <ul>
          <li><a href="...">SpaceBear 6</a></li>
          <li><a href="...">SpaceBear 6 Plus</a></li>
      </ul>
    </li>
    <li><a href="...">MarsCars</a></li>
    <li><a href="...">Contact</a></li>
  </ul>
</nav>

Ensure that all interactive elements are keyboard accessible
Think about keyboard access, especially when developing interactive elements, such as menus, mouseover information, collapsable accordions, or media players. Use tabindex="0" to add an element that does not normally receive focus, such as <div> or <span>, into the navigation order when it is being used for interaction. Use scripting to capture and respond to keyboard events.
Example: Keyboard accessible menu button
Rendered
 

Code Snippet
var buttonExample = document.getElementById('example-button');

buttonExample.addEventListener('keydown', function(e) {
  // Toggle the menu when RETURN is pressed
  if(e.keyCode && e.keyCode == 13) {
    toggleMenu(document.getElementById('example-button-menu'));
  }
});

buttonExample.addEventListener('click', function(e) {
// Toggle the menu on mouse click
  toggleMenu(document.getElementById('example-button-menu'));
});

Don’t use ARIA, use native HTML instead
Use native HTML elements or attributes first, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible.
To construct the checkbox on a web page, use HTML native checkbox (e.g. <input type=”checkbox”>) rather than ARIA role checkbox on a non-sematic element (e.g. <div role=”checkbox”>…</div>). The reason for this is that HTML checkbox conveys the semantics to people using assistive technology (such as screen readers) without any additional effort because it is already mapped to the accessibility APIs.

Avoid CAPTCHA where possible
CAPTCHAs create problems for many people. There are other means of verifying that user input was generated by a human that are easier to use, such as automatic detection or interface interactions. If CAPTCHA really needs to be included, ensure that it is simple to understand and includes alternatives for users with disabilities, such as:
•	Providing more than two ways to solve the CAPTCHAs
•	Providing access to a human representative who can bypass CAPTCHA
•	Not requiring CAPTCHAs for authorized users.
















Custom Elements:

    	                       	                	           
    Accordion	 	      Breadcrumb		    Button                          Checkbox		
                                                         
    Combobox                             Carousel	           Dialog (Modal)	               Disclosure	
   (with listbox)

                     	                            	              
       Menubar		        Menu Button	             Radiogroup                              Tabs		 

    
         Tooltip
Accordion
Accordions are a common UX pattern that can help reduce the amount of information presented to users. An accordion is a widget that vertically stacked set of interactive headings that each contain a title, and a section of content. The headings function as controls that enable users to reveal or hide their associated sections of content. Accordions are commonly used to maintain the focus of a user's attention by reducing clutter, confusion and cognitive workload. 
An accordion is a list of items, each composed with two parts: a header and a panel:
Header:
Summary of the section of content we want to hide/show. It serves as a control for showing and hiding the section of content. It usually contains a title describing the section, and a visual indicator of the visibility state of the accordion item.
Panel:
Section of content (to show/hide) associated with an accordion header. When the accordion is closed, the content inside the panel shouldn't be visible or interactable (example: focusable elements shouldn't be focusable when they are not visible on screen).
Example:
The example section below has 2 sections that demonstrate the Accordion element.
<div id=“accordionGroup” class=“accordion”>
  <h3>
    <button type=“button” aria-expanded=“true” class=“accordion_trigger” aria-controls=“sect1" id=“accordion1id”>
      <span class=“accordion_title”>
        Accordion Header 1
        <span class=“accordion_icon”></span>
      </span>
    </button>
  </h3>
  <div id=“sect1" role=“region” aria-labelledby=“accordion1ID” class=“accordion_panel”>
    <div>
    Accordion content 1 goes here
    </div>
  </div>
  <h3>
    <button type=“button” aria-expanded=“false” class=“accordion_trigger” aria-controls=“sect2” id=“accordion2id”>
      <span class=“accordion_title”>
       Accordion Header 2
        <span class=“accordion_icon”></span>
      </span>
    </button>
  </h3>
  <div id=“sect2” role=“region” aria-labelledby=“accordion2ID” class=“accordion_panel” hidden=“”>
    <div>
        Accordion content 2 goes here
    </div>
  </div>
</div>

Keyboard Interaction:

Section	Key	Action	Required
Accordion header	Enter or Space	Expands / Collapse the associated panel	Yes
	Tab	Moves focus to the next focusable element (visible on the page)	Yes
	Shift + Tab	Moves focus to the previous focusable element (visible on the page);	Yes
	Up Arrow	Moves focus to the previous accordion header.	No
	Down Arrow	Moves focus to the next accordion header.	No
	Home	Moves focus to the first accordion header.	No
	End	Moves focus to the last accordion header.	No


WAI-ARIA Roles, States, and Properties:
•	The title of each accordion header is contained in an element with a role button.
•	Each accordion header button is wrapped in an element with role heading that has a value set for “aria-level” that is appropriate for the information architecture of the page.
o	The button element is the only element inside the heading element. That is, if there are other visually persistent elements, they are not included inside the heading element.
•	If the accordion panel associated with an accordion header is visible, the header button element has “aria-expanded” set to true. If the panel is not visible, “aria-expanded” is set to false.
•	The accordion header button element has aria-controls set to the ID of the element containing the accordion panel content.
•	If the accordion panel associated with an accordion header is visible, and if the accordion does not permit the panel to be collapsed, the header button element has “aria-disabled” set to true.
•	Optionally, each element that serves as a container for panel content has role region and “aria-labelledby” with a value that refers to the button that controls display of the panel.


Breadcrumb 
Breadcrumb allows users to keep track of their present location in relation to the website’s architecture and navigate through the parent pages. In other words, a breadcrumb trail consists of a list of links to the parent pages of the current page in hierarchical order.
It allows users to find their place within a website or web application. Breadcrumbs are often placed horizontally before a page's main content.
Structure:
•	The navigation region must be announced via a nav element with an appropriate aria-label attribute. This will allow screen reader users to identify this component clearly. 
•	The breadcrumb must be structured as a list, and every list item must be a link except the last item, as mentioned above.
•	The last item must announce that it’s the current page with the aria-current attribute set to page.
•	Symbols between the list items (e.g. greater than symbol (>) and the forward slash (/)) must be hidden from the screen reader. 

Example:
HTML Source Code
<nav aria-label="Breadcrumb" class="breadcrumb"> 
  <ol> 
    <li> <a href="../../../..">Page 1</a> </li> 
    <li> <a href="../../../">Page 2</a> </li> 
    <li> <a href="../../">Page 3 </a> </li> 
    <li><a href="" aria-current="page">Current Page</a> </li> 
  </ol> 
</nav>

Keyboard Interaction:
Not applicable.
WAI-ARIA Roles, States, and Properties:
•	The Breadcrumb trail must be within a navigation landmark region (<nav> landmark).
•	The landmark region is labelled via “aria-label” or “aria-labelledby”.
•	The link to the current page has “aria-current” set to page (e.g. aria-current=”page”) and if the element representing the current page is not a link, aria-current is optional.

Button
A button is a widget that enables users to trigger an action, such as submitting a form, opening a dialog, canceling an action, or performing a delete operation. 
Sometimes, design requirements mean to create an interactive element from a base <div> element or a custom element like <my-button> rather than using a native HTML element. Along with <div> element it is required to add role=”button” which will inform assistive technologies that it’s a button control. Also, that button element will not be accessible by keyboard unless it is included in focus order (using tabindex=”0”), and it can be activated using the ENTER and SPACE keys.
In addition to the ordinary button widget, WAI-ARIA supports 2 other types of buttons:
•	Toggle button: A two-state button that can be either off (not pressed) or on (pressed). To tell assistive technologies that a button is a toggle button, specify a value for the attribute “aria-pressed”. For example, a button labelled mute in an audio player could indicate that sound is muted by setting the pressed state true. 
•	Menu button: as described in the menu button pattern, a button is revealed to assistive technologies as a menu button if it has the property “aria-haspopup” set to either menu or true.
Example:
<p>This <q>Print</q> action button uses a <code>div</code> element </p>
<div tabindex="0" role="button" id="action">Print Page</div>

<p>This <q>Mute</q> toggle button uses an <code>a</code> element </p>
<a tabindex="0" role="button" id="toggle" aria-pressed="false">
  Mute
  <svg aria-hidden="true" focusable="false">
    <use xlink:href="#icon-sound"></use>
  </svg>
</a>
         
Keyboard Interaction:

Section	Key	Action	Required
Button	Enter or Space	Activates the button.	Yes
	Space	Activates the button.	Yes

Focus management, after activating a button. For example:
•	If activating the button opens a dialog, the focus moves inside the dialog. 
•	If activating the button closes a dialog, focus typically returns to the button that opened the dialog unless the function performed in the dialog context logically leads to a different element. 
•	If activating the button does not dismiss the current context, then focus typically remains on the button after activation.
•	If the button action indicates a context change, such as move to next step in a wizard or add another search criteria, then it is often appropriate to move focus to the starting point for that action.
•	If the button is activated with a shortcut key, the focus usually remains in the context from which the shortcut key was activated.

WAI-ARIA Roles, States, and Properties:
•	The button has the role of button (role=”button”).
•	The button has an accessible label. By default, the accessible name is computed from any text content inside the button element. However, it can also be provided with “aria-labelledby” or “aria-label”.
•	If a description of the button's function is present or if there is any additional information, then the button element has “aria-describedby” set to the ID of the element containing the description.
•	When the action associated with a button is unavailable, the button has “aria-disabled” set to true.
•	If the button is a toggle button, it has a “aria-pressed” state. When the button is pressed, the value of this state is true, and when it's not pressed, the state is false.


Carousel

A carousel presents a set of photos, videos or content (each item on each slide) which rotates on a website. Dynamic carousels display various content of the same type or topic at a certain motion, speed, and time while static carousels are navigated manually with side buttons or arrows. In some implementations, rotation automatically starts when the page loads, and it may also automatically stop once all the slides have been displayed. While a slide may contain any type of content, image carousels where each slide contains nothing more than a single image are common.
Features below to provide sufficient rotation control include:
•	Buttons for the previous and next slides.
•	Optionally, a control, or group of controls, for choosing a specific slide to display.
•	If the carousel can automatically rotate, should also has:
o	A button to stop and restart rotation. This is particularly important for supporting assistive technologies operating.
o	Stops rotating when keyboard focus enters the carousel, and it does not restart unless the user explicitly requests it to do so.
o	Stops rotating whenever the mouse is hovering over the carousel.

Example: 
<section id="CarouselID" class="carousel" aria-roledescription="carousel" aria-label="Test label">
        <div class="carousel_inner">
          <div class="controls">
            <button type="button" class="rotation pause" aria-label="Stop automatic slide show">...</button>
            <button type="button" class="previous" aria-controls="myCarousel_items" aria-label="Previous Slide">...</button>
            <button type="button" class="next" aria-controls="myCarousel_items" aria-label="Next Slide">...</button>
          </div>
          <div id="myCarousel_items" class="carousel-items" aria-live="off">
            <div class="carousel-item active" role="group" aria-roledescription="slide" aria-label="1 of 4">
              <div class="carousel_image">
                <a href="#">
                  <img src="..." alt="Test alternative text">
                </a>
              </div>
              <div class="carousel_caption">
                <h2>
                  <a href="#" id="carousel_label_1"> Test heading 1 </a>
                </h2>
                <div class="hidden_xs hidden_sm">
                  <p><span class="contrast">March 13, on TV</span></p>
                </div>
              </div>
            </div>
            <div class="carousel_item" role="group" aria-roledescription="slide" aria-label="2 of 4">
              <div class="carousel_image">
                <a href="#">
                  <img src="..." alt="Test alternative text">
                </a>
              </div>
              <div class="carousel_caption">
                <h2>
                  <a href="#" id="carousel_label_2"> Test heading 2 </a>
                </h2>
                <div>
                  <p><span class="contrast">Sept. 20</span></p>
                </div>
              </div>             
            </div>       
            <div class="carousel_item" role="group" aria-roledescription="slide" aria-label="3 of 4">
              <div class="carousel_image">
                <a href="#">
                  <img src="..." alt="Test alternative text">
                </a>
              </div>
              <div class="carousel_caption">
                <h2>
                  <a href="#" id="carousel_label_3"> Test heading 3 </a>
                </h2>
                <div><p><span class="contrast">Oct. 20</span></p></div>
              </div>          
            </div>
            <div class="carousel_item" role="group" aria-roledescription="slide" aria-label="4 of 4">
              <div class="carousel_image">
                <a href="#">
                  <img src="..." alt="A man in a suit and fedora and a woman with coiffed hair look sternly into the camera.">
                </a>
              </div>
              <div class="carousel_caption">
                <h2>
                  <a href="#" id="carousel_label_4"> Test heading 4</a>
                </h2>
                <div>
                  <p><span class="contrast">10 pm Saturday, Feb. 18.</span></p>
                </div>
              </div>        
            </div>            
          </div>
        </div>     
      </section>

Keyboard Interaction:

Section	Key	Action	Required
Carousel	Tab 
& 
Shift + Tab	Move focus through the focusable elements of the carousel as specified by the page tab sequence.	Yes

Note: 
•	If the carousel has an auto-rotate feature, automatic slide rotation stops when any element in the carousel receives keyboard focus. It does not resume unless the user activates the rotation control.
•	Activating the rotation control, next slide, and previous slide do not move focus, so users may easily repetitively activate them as many times as desired.

WAI-ARIA Roles, States, and Properties (Basic Carousel):
•	A carousel container element that encompasses all components of the carousel, including both carousel controls and slides, has either role region or role group. The most appropriate role for the carousel container depends on the information architecture of the page. See the Landmark Regions Practice to determine whether the carousel warrants being designated as a landmark region.
•	The carousel container has the aria-roledescription property set to carousel.
•	If the carousel has a visible label, its accessible label is provided by the property aria-labelledby on the carousel container set to the ID of the element containing the visible label. Otherwise, an accessible label is provided by the property aria-label set on the carousel container. Note that since the aria-roledescription is set to "carousel", the label does not contain the word "carousel".
•	The rotation control, next slide control, and previous slide control are either native button elements (recommended) or implement the button pattern.
•	The rotation control has an accessible label provided by either its inner text or aria-label. The label changes to match the action the button will perform, e.g., "Stop slide rotation" or "Start slide rotation". A label that changes when the button is activated clearly communicates both that slide content can change automatically and when it is doing so. Note that since the label changes, the rotation control does not have any states, e.g., aria-pressed, specified.
•	Each slide container has role group with the property aria-roledescription set to slide.
•	Each slide has an accessible name:
o	If a slide has a visible label, its accessible label is provided by the property aria-labelledby on the slide container set to the ID of the element containing the visible label.
o	Otherwise, an accessible label is provided by the property aria-label set on the slide container.
o	If unique names that identify the slide content are not available, a number and set size can serve as a meaningful alternative, e.g., "3 of 10". Note: Normally, including set position and size information in an accessible name is not appropriate. An exception is helpful in this implementation because group elements do not support aria-setsize or aria-posinset. The tabbed carousel implementation pattern does not have this limitation.
o	Note that since the aria-roledescription is set to "slide", the label does not contain the word "slide."
•	Optionally, an element wrapping the set of slide elements has aria-atomic set to false and aria-live set to:
o	off: if the carousel is automatically rotating.
o	polite: if the carousel is NOT automatically rotating.

Checkcbox

A checkbox is a graphical widget that allows the user to make a binary choice, i.e. a choice between one of two possible mutually exclusive options.
Apart from native checkbox, using WAI-ARIA there is an option to create custom checkbox. But in this case, we need to make sure our checkboxes and radio buttons remain accessible to assistive technology (AT) and keyboard users.

Example:
<h2 id="group_label_ID"> Checkbox group heading</h2>
<div role="group" aria-labelledby=" group_label_ID"">
  <ul class="checkboxClass">
    <li><div role="checkbox" aria-checked="false" tabindex="0">Checkbox 1</div></li>
    <li><div role="checkbox" aria-checked="true" tabindex="0"> Checkbox 2</div></li>
    <li><div role="checkbox" aria-checked="false" tabindex="0"> Checkbox 3</div></li>
    <li><div role="checkbox" aria-checked="false" tabindex="0"> Checkbox 4</div></li>
  </ul>
</div>
        
Keyboard Interaction:
When the checkbox has focus, pressing the Space key changes the state of the checkbox.

WAI-ARIA Roles, States, and Properties:
•	The checkbox has role checkbox (role=”checkbox”).
•	The checkbox has an accessible label provided by one of the following:
o	Visible text content contained within the element with role checkbox.
o	A visible label referenced by the value of “aria-labelledby” set on the element with role checkbox.
o	“aria-label” set on the element with role checkbox.
•	When checked, the checkbox element has state aria-checked set to true (e.g. aria-checked=”true”) and when not checked, it has state aria-checked set to false (e.g. aria-checked=”false”).
•	If a set of custom checkboxes is presented as a logical group with a visible label, the checkboxes are included in an element with role group (role=”group”) that has the property “aria-labelledby” set to the ID of the element containing the label.

Combobox
A composite widget containing a single-line textbox and another element, such as a listbox or grid or dialog, that can dynamically pop up to help the user set the value of the textbox.

Example (Editable Combobox with both List and Inline Autocomplete):
<label for="cb1_input">State</label>
<div class="combobox combobox_list">
  <div class="group">
    <input id="cb1_input" class="cb_edit" type="text" role="combobox" aria-autocomplete="both" aria-expanded="false" aria-controls="cb1_listbox">
    <button type="button" id="cb1_button" aria-label="english alphabets" aria-expanded="false" aria-controls="cb1_listbox" tabindex="-1">
      <svg width="18" height="16" aria-hidden="true" focusable="false" style="forced-color-adjust: auto">
        <polygon class="arrow" stroke-width="0" fill-opacity="0.75" fill="currentcolor" points="3,6 15,6 9,14"></polygon>
      </svg>
    </button>
  </div>
  <ul id="cb1_listbox" role="listbox" aria-label="english alphabets">
    <li id="lb_a" role="option">A</li>
    <li id="lb_b" role="option">B</li>
    <li id="lb_c" role="option">C</li>
    <li id="lb_d" role="option">D</li>
    <li id="lb_e" role="option">E</li>
    <li id="lb_f" role="option">F</li>
  </ul>
</div>

Keyboard Interaction:

Section	Key	Action	Required
Combobox	Tab	The combobox is in the page Tab sequence.	Yes
	Down Arrow	If the popup is available, it moves focus into the popup. places focus on the first focusable element in the popup.	Yes
	Up Arrow	If the popup is available, places focus on the last focusable element in the popup.	No
	ESC	Dismisses the popup if it is visible. Optionally, if the popup is hidden before Escape is pressed, clears the combobox.	Yes
	Enter	If the combobox is editable and an autocomplete suggestion is selected in the popup, it accepts the suggestion either by placing the input cursor at the end of the accepted value in the combobox or by performing a default action on the value. For example, in a messaging application, the default action may be to add the accepted value to a list of message recipients and then clear the combobox so the user can add another recipient.	Yes
Listbox Popup
	Enter	Accepts the focused option in the listbox by closing the popup, placing the accepted value in the combobox, and if the combobox is editable, placing the input cursor at the end of the value.	Yes
	Down Arrow	Moves focus to and selects the next option. If focus is on the last option, either returns focus to the combobox or does nothing.	Yes
	Up Arrow	Moves focus to and selects the previous option. If focus is on the first option, either returns focus to the combobox or does nothing.	Yes
	Right Arrow	If the combobox is editable, returns focus to the combobox without closing the popup and moves the input cursor one character to the right. If the input cursor is on the right-most character, the cursor does not move.	Yes
	Left Arrow	If the combobox is editable, returns focus to the combobox without closing the popup and moves the input cursor one character to the left. If the input cursor is on the left-most character, the cursor does not move.	Yes
	Home	Either moves focus to and selects the first option or, if the combobox is editable, returns focus to the combobox and places the cursor on the first character.	No
	End	Either moves focus to the last option or, if the combobox is editable, returns focus to the combobox and places the cursor after the last character.	No
	Backspace	If the combobox is editable, returns focus to the combobox and deletes the character prior to the cursor.	No
	Delete	If the combobox is editable, returns focus to the combobox, removes the selected state if a suggestion was selected, and removes the inline autocomplete string if present.	No

WAI-ARIA Roles, States, and Properties:
•	The element that serves as an input and displays the combobox value has role combobox (role=”combobox”).
•	The combobox element has “aria-controls” set to a value that refers to the element that serves as the popup. Note that “aria-controls” only needs to be set when the popup is visible. However, it is valid to reference an element that is not visible.
•	The popup is an element that has role “listbox”, “tree”, “grid”, or “dialog”.
•	If the popup has a role other than listbox, the element with role combobox has “aria-haspopup” set to a value that corresponds to the popup type. That is, “aria-haspopup” is set to grid, tree, or dialog. Note that elements with role combobox have an implicit aria-haspopup value of listbox.
•	When the combobox popup is not visible, the element with role combobox has “aria-expanded” set to false. When the popup element is visible, “aria-expanded” is set to true. Note that elements with role combobox have a default value for “aria-expanded” of false.
•	When a combobox receives focus, DOM focus is placed on the combobox element.
•	When a descendant of a listbox, grid, or tree popup is focused, DOM focus remains on the combobox and the combobox has aria-activedescendant set to a value that refers to the focused element within the popup.
•	For a combobox that controls a listbox, grid, or tree popup, when a suggested value is visually indicated as the currently selected value, the option, gridcell, row, or treeitem containing that value has aria-selected set to true.
•	If the combobox has a visible label and the combobox element is an HTML element that can be labelled using the HTML label element (e.g., the input element), it is labeled using the label element. Otherwise, if it has a visible label, the combobox element has aria-labelledby set to a value that refers to the labelling element. Otherwise, the combobox element has a label provided by aria-label.
•	The combobox element has aria-autocomplete set to a value that corresponds to it autocomplete behavior:
o	none: When the popup is displayed, the suggested values it contains are the same regardless of the characters typed in the combobox.
o	list: When the popup is triggered, it presents suggested values. If the combobox is editable, the values complete or logically correspond to the characters typed in the combobox.
o	both: When the popup is triggered, it presents suggested values that complete or logically correspond to the characters typed in the combobox. In addition, the portion of the selected suggestion that has not been typed by the user, known as the completion string, appears inline after the input cursor in the combobox. The inline completion string is visually highlighted and has a selected state.

Dialog (Modal)
A modal is a dialog box/popup window that is displayed on top of the current page and requires a user action to close it. The dialog is only available to users when the modal is active. When the modal is active, the rest of the page is unavailable by mouse, keyboard, touch, or screen reader.
Example:
<div id="dialogID" role="dialog" aria-labelledby="dialog_label" aria-describedby="dialog_desc" aria-modal="true" class="hidden">
    <h2 id="dialog_label" class="dialog_label">Dialog heading</h2>
    <p id="dialog_desc" class="dialog_desc">Dialog Description</p>
    <div class="dialog_form_actions">
      <button type="button" id="dialog_close_btn" onclick="closeDialog(this)">OK</button>
      <button type="button" onclick="closeDialog(this)">Close</button>
    </div>
  </div>

Keyboard Interaction:

When a dialog opens, focus moves to an element inside the dialog. 
Section	Key	Action	Required
Dialog	Tab	•	Moves focus to the next tabbable element inside the dialog.
•	If focus is on the last tabbable element inside the dialog, moves focus to the first tabbable element inside the dialog.	Yes
	Shift + Tab	•	Moves focus to the previous tabbable element inside the dialog.
•	If focus is on the first tabbable element inside the dialog, it moves focus to the last tabbable element inside the dialog.	Yes
	ESC	•	Closes the dialog. 
•	Focus returns to the element that invoked the dialog	Yes

WAI-ARIA Roles, States, and Properties:
•	The element that serves as the dialog container has a role of dialog.
•	All elements required to operate the dialog are descendants of the element that has role dialog.
•	The dialog container element has aria-modal set to true.
•	The dialog has either:
o	A value set for the aria-labelledby property that refers to a visible dialog title.
o	A label specified by aria-label.

Disclosure
A disclosure widget can reveal or disclose hidden content under a heading. It saves screen space and provides a good overview of the page content. It has two elements: a disclosure button and a section of content whose visibility is controlled by the button.
Example:
<h2><abbr title="Frequently Asked Questions">FAQ</abbr>s</h2>
<dl class="faq">
  <dt> <button type="button" aria-expanded="false" aria-controls="faq1_desc">Test question 1? </button> </dt>
  <dd><div id="faq1_desc" class="desc">Test answers 1</div></dd>
  <dt><button type="button" aria-expanded="false" aria-controls="faq2_desc">Test question 2? </button></dt>
  <dd><div id="faq2_desc" class="desc">Test answers 2</div></dd>
  <dt><button type="button" aria-expanded="false" aria-controls="faq3_desc">Test question 3? </button></dt>
  <dd> <div id="faq3_desc" class="desc">Test answers 3</div> </dd>
  <dt> <button type="button" aria-expanded="false" aria-controls="faq4_desc">Test question 4? </button> </dt>
  <dd><div id="faq4_desc" class="desc">Test answers 4</div></dd>
</dl>

Keyboard Interaction:

Section	Key	Action	Required
Button	Enter 	Activates disclosure control and toggles the visibility of the disclosure content.	Yes
	Space	Activates disclosure control and toggles the visibility of the disclosure content.	Yes

WAI-ARIA Roles, States, and Properties:
•	The element that shows and hides the content has a role button.
•	When the content is visible, the element with role button has aria-expanded set to true. When the content area is hidden, it is set to false.
•	Optionally, the element with role button has a value specified for aria-controls that refers to the element that contains all the content that is shown or hidden.



Menubar

A menubar  is often used to create a menu bar similar to those found near the top of the window in many desktop applications, offering the user quick access to a consistent set of commands. Menubar consists of multiple menus. Menus convey the menu structure, typically by using a list. Such structural information allows assistive technologies to announce the number of items in the menu and provide corresponding navigation functionality.
Example:
<nav aria-label="Mythical University">
        <ul class="menubar-navigation" role="menubar" aria-label="Mythical University">
          <li role="none"> <a role="menuitem" href="#home"> Home </a></li>
          <li role="none"> <a role="menuitem" aria-haspopup="true" aria-expanded="false" href="#about">About</a>
            <ul role="menu" aria-label="About">
              <li role="none"><a role="menuitem" href="#overview">Overview</a></li>
              <li role="none"><a role="menuitem" href="#administration">Admin</a> </li>
              <li role="none"> <a role="menuitem" aria-haspopup="true" aria-expanded="false" href="#facts">Facts </a>
                <ul role="menu" aria-label="Facts">
                  <li role="none"><a role="menuitem" href="#past">Past</a></li>
                  <li role="none"><a role="menuitem" href="#current">Current</a></li>
                </ul>
              </li>
            </ul>
          </li>
        </ul>
      </nav>

Keyboard Interaction:

Section	Key	Action	Required
Menubar	Tab

&

Shift + Tab	•	Move focus into a menubar:
o	 If focus is moving into the menubar for the first time, focus is set on the first menuitem.
o	 If the menubar has previously contained focus, focus is optionally set on the menuitem that last had focus. Otherwise, it is set on the first menuitem that is not disabled.
•	When focus is on a menuitem in a menu or menubar, move focus out of the menu or menubar, and close all menus and submenus.
•	Note that Tab and Shift + Tab do not move focus into a menu. Unlike a menubar, a menu is not visually persistent, and authors are responsible for ensuring focus moves to an item inside of a menu when the menu opens.	Yes 
	Enter	•	When focus is on a menuitem that has a submenu, opens the submenu and places focus on its first item.
•	Otherwise, activates the item and closes the menu.	Yes
	Space	•	When focus is on a menuitemcheckbox, changes the state without closing the menu.
•	When focus is on a menuitemradio that is not checked, without closing the menu, checks the focused menuitemradio and unchecks any other checked menuitemradio element in the same group.
•	When focus is on a menuitem that has a submenu, opens the submenu and places focus on its first item.
•	When focus is on a menuitem that does not have a submenu, activates the menuitem and closes the menu.	No
	Down Arrow	•	When focus is on a menuitem in a menubar, and that menuitem has a submenu, opens the submenu and places focus on the first item in the submenu.
•	When focus is on a menu, the focus moves to the next item, optionally wrapping from the last to the first.	Yes
	Up Arrow	•	When focus is on a menu, moves focus to the previous item, optionally wrapping from the first to the last.	Yes
	Right Arrow	•	When focus is in a menubar, moves focus to the next item, optionally wrapping from the last to the first.
•	When focus is on a menu and on a menuitem that has a submenu, the submenu opens and places focus on its first item.
•	When focus is on a menu and on an item that does not have a submenu, performs the following 3 actions:
o	Closes the submenu and any parent menus.
o	Moves focus to the next item in the menubar.
o	If focus is now on a menuitem with a submenu, either: (Recommended) opens the submenu of that menuitem without moving focus into the submenu or opens the submenu of that menuitem and places focus on the first item in the submenu.
Note that if the menubar were not present, e.g., the menus were opened from a menubutton, Right Arrow would not do anything when focus is on an item that does not have a submenu.
	Yes
	Left Arrow	•	When focus is in a menubar, moves focus to the previous item, optionally wrapping from the first to the last.
•	When focus is on a submenu of an item in a menu, closes the submenu and returns focus to the parent menuitem.
•	When focus is on a submenu of an item in a menubar, performs the following 3 actions:
o	Closes the submenu.
o	Moves focus to the previous item in the menubar.
o	If focus is now on a menuitem with a submenu, either: (Recommended) opens the submenu of that menuitem without moving focus into the submenu or opens the submenu of that menuitem and places focus on the first item in the submenu.	Yes
	Home	If arrow key wrapping is not supported, focus moves to the first item in the current menu or menubar.	Yes
	End	If arrow key wrapping is not supported, focus moves to the last item in the current menu or menubar.	Yes
	ESC	Close the menu that contains focus and return focus to the element or context, e.g., menu button or parent menuitem, from which the menu was opened.	Yes
WAI-ARIA Roles, States, and Properties:

•	A menu is a container of items that represent choices. The element serving as the menu has a role of either menu or menubar.
•	The items contained in a menu are child elements of the containing menu or menubar and have any of the following roles:
o	menuitem
o	menuitemcheckbox
o	menuitemradio
•	If activating an menuitem opens a submenu, the menuitem is known as a parent menuitem. A submenu's menu element is:
o	Contained inside the same menu element as its parent menuitem.
o	Is the sibling element immediately following its parent menuitem.
•	A parent menuitem has aria-haspopup set to either menu or true.
•	A parent menuitem has aria-expanded set to false when its child menu is not visible and set to true when the child menu is visible.
•	One of the following approaches is used to enable scripts to move focus among items in a menu as described in the practice for Keyboard Navigation Inside Components:
o	The menu container has tabindex set to -1 or 0 and aria-activedescendant set to the ID of the focused item.
o	Each item in the menu has tabindex set to -1, except in a menubar, where the first item has tabindex set to 0.
•	When a menuitemcheckbox or menuitemradio is checked, aria-checked is set to true.
•	When a menu item is disabled, aria-disabled is set to true.
•	Items in a menu may be divided into groups by placing an element with a role of separator between groups. For example, this technique should be used when a menu contains a set of menuitemradio items.
•	All separators should have aria-orientation consistent with the separator's orientation.
•	If a menubar has a visible label, the element with role menubar has aria-labelledby set to a value that refers to the labelling element. Otherwise, the menubar element has a label provided by aria-label.
•	If a menubar is vertically oriented, it has aria-orientation set to vertical. The default value of aria-orientation for a menubar is horizontal.
•	An element with role menu either has:
o	aria-labelledby set to a value that refers to the menuitem or button that controls its display.
o	A label provided by aria-label.
•	If a menu is horizontally oriented, it has aria-orientation set to horizontal. The default value of aria-orientation for a menu is vertical.

Menu Button

A menu button is a user interface component that is typically indicated using an icon or text that opens a menu when activated or clicked. It generally displays a list of options or actions that a user can choose from. It is often styled as a typical push button with a downward pointing arrow or triangle to hint that activating the button will display a menu.
The menu button helps users quickly navigate through different areas of the application or website.

Example:
<div class="menu_button_nav_links">
      <button type="button" id="menubutton" aria-haspopup="true" aria-controls="menu" aria-expanded="false">
        Navigation Menu button
        <svg ...>...</svg>
      </button>
      <ul id="menu" role="menu" aria-labelledby="menubutton">
        <li role="none"><a role="menuitem" href="..."> Navigation link 1 </a></li>
        <li role="none"><a role="menuitem" href="..."> Navigation link 2 </a></li>
        <li role="none"><a role="menuitem" href="..."> Navigation link 3 </a></li>
        <li role="none"><a role="menuitem" href="..."> Navigation link 4 </a></li>
        <li role="none"><a role="menuitem" href="..."> Navigation link 5 </a></li>
      </ul>
    </div>

Keyboard Interaction:

Section	Key	Action	Required
	Enter	Opens the menu and places focus on the first menu item.	Yes
	Space	Opens the menu and places focus on the first menu item.	Yes
	Down Arrow	Opens the menu and moves focus to the first menu item.	No
	Up Arrow	Opens the menu and moves focus to the last menu item.	No

Note: The keyboard behaviors needed after the menu is open are described in the Menubar element.

WAI-ARIA Roles, States, and Properties:
•	The element that opens the menu has a role button.
•	The element with role button has aria-haspopup set to either menu or true.
•	When the menu is displayed, the element with role button has aria-expanded set to true. When the menu is hidden, aria-expanded is set to false.
•	The element that contains the menu items displayed by activating the button has role menu.
•	Optionally, the element with role button has a value specified for aria-controls that refers to the element with role menu.
•	Additional roles, states, and properties needed for the menu element are described in the Menubar element.


Radio group
A radio group is a set of checkable buttons, known as radio buttons, where no more than one of the buttons can be checked at a time. Some implementations may initialize the set with all buttons in the unchecked state in order to force the user to check one of the buttons before moving past a certain point in the workflow.
Example:
<div role="radiogroup" aria-labelledby="group_label1" id="rg1">
    <h2 id="group_label1">Please select your preferred contact method:</h2>
    <div role="radio" aria-checked="false" tabindex="0">Email</div>
    <div role="radio" aria-checked="false" tabindex="-1">Phone</div>
    <div role="radio" aria-checked="false" tabindex="-1">Mail</div>
</div>

Keyboard Interaction:

Section	Key	Action	Required
Radio Groups
	Tab	Move focus into the radio group. When focus moves into a radio group:
•	If a radio button is checked, focus is set on the checked button.
•	If none of the radio buttons are checked, focus is set on the first radio button in the group.
	Yes
	Shift + Tab	Move focus out of the radio group. When focus moves into a radio group:
•	If a radio button is checked, focus is set on the checked button.
•	If none of the radio buttons are checked, focus is set on the first radio button in the group.
	Yes
	Space	Checks the focused radio button if it is not already checked.	Yes
	Enter	Checks the focused radio button if it is not already checked.	No
	Right Arrow 
+
Down Arrow
	Move the focus to the next radio button in the group, uncheck the previously focused button, and check the newly focused button. If focus is on the last button, focus moves to the first button.	Yes
	Left Arrow + Up Arrow	Move focus to the previous radio button in the group, uncheck the previously focused button, and check the newly focused button. If focus is on the first button, focus moves to the last button.
	Yes

WAI-ARIA Roles, States, and Properties:
•	The radio buttons are contained in or owned by an element with role radiogroup.
•	Each radio button element has a role radio.
•	If a radio button is checked, the radio element has aria-checked set to true. If it is not checked, it has aria-checked set to false.
•	Each radio element is labelled by its content, has a visible label referenced by aria-labelledby, or has a label specified with aria-label.
•	The radiogroup element has a visible label referenced by aria-labelledby or has a label specified with aria-label.
•	If elements providing additional information about either the radio group or each radio button are present, those elements are referenced by the radiogroup element or radio elements with the aria-describedby property.

Tabs

Tab elements are groupings of content that display one specific piece of content at a time, called a tab panel. A user interacts with a list of Tab elements also known as a tab list which can be displayed on any side of the tab panel. For better user interactions, Tab lists are typically located on the top Tab panel.
Terms used to describe a few Tab terms in the element include:
•	Tabs element: A set of tab elements and their associated tab panels.
•	Tablist: A set of tab elements contained in a tablist element.
•	Tab: An element in the tab list that serves as a label for one of the tab panels and can be activated to display that panel.
•	Tabpanel: The element that contains the content associated with a tab.

Example:
<div class="tabs">
      <h2 id="tablist">Section heading</h2>
      <nav role="tablist" aria-labelledby="tablist">
        <button id="tab-1" type="button" role="tab" aria-selected="true" aria-controls="tabpanel-1">Section 1</button>
        <button id="tab-2" type="button" role="tab" aria-selected="false" aria-controls="tabpanel-2" tabindex="-1">Section 2</button>
        <button id="tab-3" type="button" role="tab" aria-selected="false" aria-controls="tabpanel-3" tabindex="-1">Section 3</button>
      </nav>
      <section id="tabpanel-1" role="tabpanel" aria-labelledby="tab-1">
        <p>This is section 1</p>
      </section>
      <section id="tabpanel-2" role="tabpanel" aria-labelledby="tab-2" class="is-hidden">
        <p>This is section 2</p>
      </section>
      <section id="tabpanel-3" role="tabpanel" aria-labelledby="tab-3" class="is-hidden">
        <p>This is section 3</p>
      </section>
    </div>

Keyboard Interaction:

Section	Key	Action	Required
Tabs	Tab	•	When focus moves into the tab list, places focus on the active tab element.
•	When the tab list contains the focus, the focus moves to the next element in the page tab sequence outside the tablist, which is the tabpanel unless the first element containing meaningful content inside the tabpanel is focusable.	Yes
	Left Arrow	Moves focus to the previous tab. If focus is on the first tab, moves focus to the last tab. Optionally, activates the newly focused tab.	Yes
	Right Arrow	Moves focus to the next tab. If focus is on the last tab element, moves focus to the first tab. Optionally, activates the newly focused tab.	Yes

Note:
•	It is recommended that tabs activate automatically when they receive focus. This typically requires tab panel content to be preloaded. Otherwise, automatic activation slows focus movement, which significantly hampers users' ability to navigate efficiently across the tab list.
•	When a tab list has its aria-orientation set to vertical:
o	The Down Arrow performs as the Right Arrow is described above.
o	The Up Arrow is performed as the Left Arrow is described above.
•	If the tab list is horizontal, it does not listen for Down Arrow or Up Arrow so those keys can provide their normal browser scrolling functions even when focus is inside the tab list.
•	When the tabpanel does not contain any focusable elements or the first element with content is not focusable, the tabpanel should set tabindex="0" to include it in the tab sequence of the page.

WAI-ARIA Roles, States, and Properties:
•	The element that serves as the container for the set of tabs has a role tablist.
•	Each element that serves as a tab has role tab and is contained within the element with a role tablist.
•	Each element that contains the content panel for a tab has role tabpanel.
•	If the tab list has a visible label, the element with role tablist has aria-labelledby set to a value that refers to the labelling element. Otherwise, the tablist element has a label provided by aria-label.
•	Each element with role tab has the property aria-controls referring to its associated tabpanel element.
•	The active tab element has the state aria-selected set to true and all other tab elements have it set to false.
•	Each element with role tabpanel has the property aria-labelledby referring to its associated tab element.
•	If a tab element has a popup menu, it has the property aria-haspopup set to either menu or true.
•	If the tablist element is vertically oriented, it has the property aria-orientation set to vertical. The default value of aria-orientation for a tablist element is horizontal.


Tooltip

A tooltip is a popup element that provides extra information about a form field, a link, a button, or other focusable element. It must be triggered by both focus and hover events and remains on the screen if the trigger has the focus. The focus generally doesn’t not move to the tooltip. It typically appears after a small delay and disappears when Escape is pressed or on mouse out.
Example:
<p>
        <button class="tp_trigger" aria-describedby="tp_container">Example</button>
        <div id="tp_container" role="tooltip">This text tooltip which describes the button</div>
 </p>

Keyboard Interaction:

Section	Key	Action	Required
Tooltip	Tab	When focus moves to the focusable element (for example: link, button etc.), it triggers the popup tooltip element which displays additional content.	Yes
	ESC	Dismisses the Tooltip.	Yes


WAI-ARIA Roles, States, and Properties:
•	The element that serves as the tooltip container has role tooltip.
•	The element that triggers the tooltip references the tooltip element with aria-describedby.

Unit Testing
When developing a website or web application, evaluate accessibility early and throughout the development process to identify accessibility problems early, when it is easier to address them.
There are evaluation tools that help with evaluation. However, no tool alone can determine if a site meets accessibility standards. Knowledgeable human evaluation is required to determine if a site is accessible.
Using Automated tools
Depending on your needs, different types or classifications of evaluation tools offer different report formats, additional features, and benefits that can help you choose a tool for your situation. So, choosing the right tool depends on your skill set and how you define your web responsibilities.
It's often best to use a variety of tools to test various aspects of web accessibility and to get varying feedback and reports to ensure you are capturing all possible issues. But remember, automated testing alone is not enough - you will still need manual testing to ensure your content is accessible.
Below are some of the popularly used tools:

WAVE Toolbar in chrome 
  


Deque Systems Axe Chrome Extension 
 
The above-mentioned automated accessibility testing tools identifies the pages and lines of code that need to be manually checked for accessibility. 
•	checks the syntax of the site's code 
•	identify pages containing elements that may cause problems 
•	identify alt text missing for images 
•	identify the missing of form labels 
•	Captures the inappropriate usage of aria-properties and roles 
•	Color contrast ratio of the elements  
None of the automated tools conforms if a page is accessible, but these automated tools facilitate human evaluation and reveal some accessibility issues.
Valid HTML:
Browsers & assistive technologies rely on the code in DOM & render the necessary information to the users. If the code is not written according to the standards, it can impact the user experience of the application & assistive technology users especially screen reader users and even it may be interpreted differently by different user agents and the content will not be accessible as per the standard approach followed globally with respect to WCAG standards. This must be considered before setting up the code base to avoid many iterations in Ax review as changing the code structure will impact the functionalities defined. 
HTML Validator by W3C can be used to validate the HTML code
 

Markup validation ensures that the HTML of web content is well formed with  
•	elements having complete start and end tags,  
•	elements are nested according to their specifications,  
•	elements do not contain duplicate attributes, and 
•	any IDs are unique
Using Screen readers
People with visual challenges either partially or completely will use the screen reader along with keyboard navigation. A screen reader is a type of assistive technology designed to help people who are blind or visually impaired interact with digital content. It translates on-screen information into speech or Braille output, allowing users to “read” text and navigate computer interfaces through auditory means or touch.
Here’s how it works:
•	Text-to-Speech: The screen reader converts the text displayed on the screen into spoken words, enabling users to listen to the content.
•	Braille Display: For those who use Braille, the screen reader can work with a Braille display that translates text into Braille characters.
•	Navigation: Users can navigate through the content using keyboard shortcuts or gestures on a touchscreen.
•	Compatibility: Screen readers are compatible with various operating systems and applications, providing access to files, menus, and web content.
Screen readers are essential for providing equal access to information and technology for individuals with visual impairments. Testing with a screen reader can be extremely valuable, especially for more complex or dynamic content. Screen readers can also help you identify problems with reading order, table markup, form elements, and many other aspects of accessibility.
Some of the popular screen readers are:
JAWS: a popular screen reader for Windows computers to evaluate Web Accessibility. You can refer JAWS keyboard shortcuts PDF for a quick reference guide.
NVDA: is a free screen reader for Windows computers that can evaluate Web Accessibility. Refer NVDA keyboard shortcuts PDF for a quick reference guide.
VoiceOver: is a screen reader program that comes inbuilt on new Mac computers, iPhones, iPads, and iPod touches. You can find VoiceOver keyboard shortcuts PDF for reference.
Text resize
Text resize check ensures that visually rendered text, including text-based controls can be scaled successfully so that it can be read directly by people with mild visual disabilities (Low vision Users), without requiring the use of assistive technology such as a screen magnifier. Users may benefit from scaling all content on the Web page, but text is most critical.  
200% Text Resize can be validated in either of the following ways. 
•	In-built option available in Firefox browser (Alt key -> View -> Zoom -> Zoom text only) 
•	Zoom Text only Extension in Chrome browser 
Ensure the below checkpoints on zooming 
•	Font sizes increase while zooming on the page 
•	Text does not become pixelated when zooming in on the page 
•	Items do not become overlapped when zooming in on the page
Conclusion
Thanks for holding till here! Hope this Developer handbook served as a comprehensive resource for you (developers) to enable you to actively dive into the world of accessible website development. 
Takeaways
•	Familiarize WCAG and adhere to its conformance levels
•	Gain Knowledge on Accessibility concepts
•	Implement Quick tips for developing accessible web
•	Refer to the Custom elements discussed extensively
•	Self-audit assuring first level of Accessibility conformance

"The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect."
- Tim Berners-Lee, W3C Director and inventor of the World Wide Web
THANK YOU!