Ensure Custom Widgets are accessible

The HTML standard has been around for many years; browsers and assistive technology are familiar with the information and behaviours associated with standard, “out-of-the-box” HTML elements. If you are creating your own custom widgets you need to ensure they are coded in a way that allows both users and technology to predict how they will behave.

For custom widgets not included in this section, please refer to WAI-ARIA Authoring Practices 1.2 on Design Patterns and Widgets

On this page

In this section

Make carousels accessible
Create accessible accordions
Create accessible modal dialogues
Make sure login and authentication processes are accessible
Ensure embedded social media code is accessible

References for this section

WCAG 2.1

1.3.1 Info and Relationships (A)
1.3.4 Identify Input Purpose (AA)
1.3.6 Identify Purpose (AAA)
2.1.1 Keyboard (A)
2.1.2 No Keyboard Trap (A)
2.2.1 Timing Adjustable (A)
2.2.2 Pause, Stop Hide (A)
2.4.1 Bypass Blocks (A)
2.4.3 Focus Order (A)
2.4.6 Headings and Labels (AA)
2.4.7 Focus Visible (AA)
3.2.5 Change on Request (AAA)
4.1.2 Name, Role, Value (A)

EN 301 549 v 2.1.2

9.1.3.1 Info and Relationships
9.1.3.4 Identify Input Purpose
9.2.1.1 Keyboard
9.2.1.2 No Keyboard Trap
9.2.2.1 Timing Adjustable
9.2.2.2 Pause, Stop Hide
9.2.4.1 Bypass Blocks
9.2.4.3 Focus Order
9.2.4.6 Headings and Labels
9.2.4.7 Focus Visible
9.4.1.2 Name, Role, Value

Ensure Custom Widgets are accessible

Web Accessibility Techniques

In this section

References for this section

WCAG 2.1

EN 301 549 v 2.1.2

Further reading