New to Kendo UI for Angular? Start a free 30-day trial

Accessibility Compliance

The accessibility support available for the Kendo UI for Angular components is based on a set of approaches for adhering to and implementing the established standards and technical specifications ensuring the seamless experience of users with disabilities.

Accessibility Approaches in Kendo UI for Angular

The following list summarizes how the Kendo UI for Angular team approaches accessibility when developing the component library:

  • When implementing a Kendo UI for Angular component, the team follows the WAI-ARIA specification to ensure that the right foundation for the accessibility of the component is laid.
  • From there, to guarantee accessible and semantically correct rendering, the team employs both multiple automated tests and unit tests across the Kendo UI for Angular library.
  • The team also ensures the proper usage of WAI-ARIA attributes and localized messages for labels, titles, and other elements.
  • Additionally, each component also goes through manual testing, which covers its usage with various screen readers and other accessibility aspects such as keyboard navigation.

The team sometimes runs into scenarios not covered by the WAI-ARIA specifications. In those cases, the team taps into the web development accessibility know-how of the rest of the Progress organization. This includes feedback from accessibility-minded users and the team's expertise based on 10+ years of creating web component libraries. The knowledge-sharing across internal teams and clients helps ensure that Kendo UI for Angular can reach a certain level of accessibility compliance even with its most advanced components.

Due to the rich feature set of the library and complexity of some components, the specific combination of configuration options may lead to inaccessible component rendering. Perform thorough testing on any modifications applied to the Kendo UI for Angular components to ensure that they continue to comply with the desired level of accessibility standards.

Voluntary Product Accessibility Template (VPAT)

A Voluntary Product Accessibility Template (VPAT®) is a document that explains how information and communication technology (ICT) products such as software, hardware, electronic content, and support documentation meet (conform to) the Revised 508 Standards for IT accessibility.

You can review and download the latest version of the Kendo UI for Angular VPAT document here.

Accessibility Support per Component

The following table lists the accessibility compliance levels and keyboard navigation support provided by the Kendo UI for Angular components.

The described level of compliance in the table below is achievable with the Ocean Blue A11y Accessibility Swatch.

ComponentSection 508WCAG 2.2Keyboard NavigationAccessibility Documentation
ActionSheetYesAAYesDocumentation
AppBarYesAAYesn/a
ArcGaugeYesYesn/an/a
AutoCompleteYesAAYesDocumentation
AvatarYesAAn/an/a
BadgeYesn/an/an/a
BarcodeYesn/an/an/a
BottomNavigationYesAAYesDocumentation
BreadcrumbYesAAYesDocumentation
ButtonYesAAYesn/a
ButtonGroupYesAAYesDocumentation
CalendarYesAAYesDocumentation
CardYesAAAYesn/a
ChartYesYesn/an/a
CheckboxYesAAYesn/a
ChipYesAAYesDocumentation
ChipListYesAAYesDocumentation
ChunkProgressBarYesAAn/aDocumentation
CircularGaugeYesYesn/an/a
CircularProgressBarYesAAn/aDocumentation
ColorGradientYesAAYesDocumentation
ColorPaletteYesAAYesDocumentation
ColorPickerYesAAYesDocumentation
ComboBoxYesAAYesDocumentation
ContextMenuYesAAYesDocumentation
Conversational UIYesAAYesDocumentation
DateInputYesAAYesDocumentation
DatePickerYesAAYesDocumentation
DateRangeYesAAYesDocumentation
DateTimePickerYesAAYesDocumentation
DialogYesAAYesDocumentation
DrawerYesAAYesDocumentation
DropDownButtonYesAAYesDocumentation
DropDownListYesAAYesDocumentation
DropDownTreeYesAAYesDocumentation
EditorYesAAYesDocumentation
ExpansionPanelYesAAYesDocumentation
FileSelectYesn/aYesDocumentation
FilterYesAAYesDocumentation
FlatColorPickerYesAAYesDocumentation
FloatingActionButtonYesAAYesDocumentation
FloatingLabelYesn/an/an/a
GanttYesAAYesDocumentation
GridYesAAYesDocumentation
GridLayoutYesn/an/an/a
Iconn/an/an/an/a
Labeln/an/an/an/a
LinearGaugeYesYesn/an/a
ListBoxYesAAYesDocumentation
ListViewYesAAAYesDocumentation
Loadern/an/an/an/a
Mapn/an/an/an/a
MaskedTextBoxYesAAYesDocumentation
MenuYesAAYesDocumentation
MultiColumnComboBoxYesAAYesDocumentation
MultiSelectYesAAYesDocumentation
MultiSelectTreeYesAAYesDocumentation
MultiViewCalendarYesAAYesDocumentation
NotificationYesAAn/an/a
NumericTextBoxYesAAYesDocumentation
PagerYesAAYesDocumentation
PanelBarYesAAYesDocumentation
PivotGridYesAAYesDocumentation
PopoverYesAAYesDocumentation
ProgressBarYesAAn/aDocumentation
QR Coden/an/an/an/a
RadialGaugeYesYesn/an/a
RadioButtonYesAAYesn/a
RangeSliderYesAAYesDocumentation
RippleYesAAAn/an/a
SchedulerYesAAYesDocumentation
SignatureYesYesYesn/a
Skeletonn/an/an/an/a
ScrollViewYesAAYesDocumentation
SliderYesAAYesDocumentation
SortableYesAAYesDocumentation
SparklineYesYesn/an/a
SplitButtonYesAAYesDocumentation
SplitterYesAAYesDocumentation
StackLayoutYesn/an/an/a
StepperYesAAYesDocumentation
StockChartYesYesn/an/a
SVGIconYesn/an/an/a
SwitchYesAAYesDocumentation
TabStripYesAAYesDocumentation
TextAreaYesAAAYesDocumentation
TextBoxYesAAYesDocumentation
TileLayoutYesAAAYesDocumentation
TimePickerYesAAYesDocumentation
ToolBarYesAAYesDocumentation
TooltipYesAAYesDocumentation
TreeListYesAAYesDocumentation
TreeViewYesAAYesDocumentation
UploadYesAAAYesDocumentation
WindowYesAAYesDocumentation

Special Considerations 

  • The components that represent or directly extend a native HTML element (for example Button, CheckBox) do not require additional accessibility functionality to provide their respective level of compliance.

  • Components that are built by using other components and/or native HTML elements that are fully accessible (for example Card, AppBar, Pager), achieve their respective level of compliance through their building blocks.

  • Components that do not provide end-user interaction and serve only as visual representation of a specific state, value, actions, and others (for example, Icons and ProgressBars) are neither focusable, nor navigable. Adding descriptive labels, WAI-ARIA attributes, or a tabindex to such components, necessitated by a specific use case, is in the hands of the developer.

  • Assistive technologies treat components like the various Charts and Gauges as images. To make them accessible, add a descriptive label or an alternative representation of the data. For example, a Chart may be represented by a table that duplicates the data in an accessible form.

Component Customization

Note that the Kendo UI for Angular components are highly extensible and customizable. This means that, depending on the applied level of customization, you may be introducing rendering that is not accessible.

Therefore, it is recommended to test any modifications made to the Kendo UI for Angular components to ensure that they still meet the desired level of accessibility standards. Additionally, be mindful of components working with templates and custom input (for example, images, text, and HTML content), make sure that any custom content is also accessible.