Build your web apps using Smart UI
Accessibility of Smart HTML Elements
WAI-ARIA, WCAG 2.0, and Section 508
Accessibility support means that the web applications provide full control over their features by enabling users with disabilities to access them through assistive technologies such as screen readers.
The custom elements in the Smart HTML Elements framework are made accessible to all users by conforming to web standards WAI-ARIA, Section 508, and WCAG, and by testing with state-of-the-art accessibility development tools Google Chrome Lighthouse and Firefox Accessibility Inspector.
Below is an overview of the features implemented by Smart HTML Elements in order to make the elements accessible.
WAI-ARIA (Accessible Rich Internet Applications)
Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA) is a technical specification published by the World Wide Web Consortium (W3C) that specifies how to increase the accessibility of web pages, in particular, dynamic content, and user interface components developed with Ajax, HTML, JavaScript, and related technologies. Smart HTML Elements conform to WAI-ARIA 1.1, the latest version of the standard.
Each custom element follows the guidelines presented on the WAI-ARIA Authoring Practices 1.1 page and adopts the roles and aria- properties necessary for screen readers to correctly interpret the semantics and functionality of an element for visually-impaired users or other users in need of assistive technology.
Keyboard navigation is also available for elements where applicable. For more information, please visit the Keyboard Navigation of Smart HTML Elements page.
As per the guidelines, form-related custom elements are provided accessible labels. In many cases, the accessible label of an element is linked to the setting of the respective label property (e.g. Smart.NumericTextBox, Smart.TextBox). In other cases, accessible labels are calculated based on the element's content (e.g. Smart.Button).
Example
In order to become accessible, the Smart.Menu web component has its role attribute set to menu, menu items have the role menuitem and elements that do not contribute to the element's semantics have role presentation. This results in the following DOM tree structure of the Menu:
to be interpreted as follows by assistive technology (image from Firefox Accessibility Inspector):
Each menu item has an accessible label linked with its respective label property.
Section 508
Section 508 of the Rehabilitation Act requires information and communications technology (ICT) that is accessible to people with disabilities. The US Access Board established the Section 508 standards that implement the law and provides the requirements for accessibility.
Section 508 establishes a set of standards that have been adopted by Smart HTML Elements, where applicable. You can find a Section 508 compiance table below (list of criteria from https://www.webaccessibility.com/best_practices.php?standard_id=1000703):
| Criteria | Compliance | Notes |
|---|---|---|
| (a) A text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content). | Yes | |
| (b) Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation. | Not applicable | Smart HTML Elements does not provide video-related elements. |
| (c) Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup. | Yes | Active, hover, and focus states are implemented through HTML attributes (markup). |
| (d) Documents shall be organized so they are readable without requiring an associated style sheet. | Partial | Smart HTML Elements rely on CSS for their look. However, with ARIA roles and attributes implemented, assistive techology can correctly interpret the structure of an element. Moreover, the underlying JavaScript functionality continues to function. |
| (e) Redundant text links shall be provided for each active region of a server-side image map. | Not applicable | Image maps are not used in Smart HTML Elements. |
| (f) Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape. | Not applicable | Image maps are not used in Smart HTML Elements. |
| (g) Row and column headers shall be identified for data tables. | Yes | |
| (h) Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers. | Yes | |
| (i) Frames shall be titled with text that facilitates frame identification and navigation. | Not applicable | Frames are not used in Smart HTML Elements. |
| (j) Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz. | Yes | |
| (k) A text-only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of this part, when compliance cannot be accomplished in any other way. | Not applicable | Smart HTML Elements are integrated in developer-created pages and developers are responsible for implementing this standard. |
| (l) When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology. | Yes | WAI-ARIA roles and attributes have been implemented. |
| (m) When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with §1194.21(a) through (l). | Yes | Smart HTML Elements does not depend on third-party plug-ins. |
| (n) When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form | Yes | Form Smart HTML Elements have label and hint parts and the relevant WAI-ARIA roles and attributes, as well as keyboard support. |
| (o) A method shall be provided that permits users to skip repetitive navigation links. | Not applicable | Repetitive navigation links are not part of any Smart custom element. |
| (p) When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required. | Yes | Elements such as Smart.Toast have properties for controlling the time of showing or hiding (such as autoCloseDelay). |
The compliance with Section 508 makes Smart HTML Elements suitable for US Federal-funded web-based applications.
WCAG (Web Content Accessibility Guidelines)
Web Content Accessibility Guidelines (WCAG) 2.1 is a wide range of recommendations for making Web content more accessible. Following these guidelines makes Smart HTML Elements more accessible to a wider range of people with disabilities, including accommodations for blindness and low vision, deafness and hearing loss, limited movement, speech disabilities, photosensitivity, and combinations of these, and some accommodation for learning disabilities and cognitive limitations. These guidelines address accessibility of web content on desktops, laptops, tablets, and mobile devices. Following these guidelines also makes Web content more usable to users in general.
There are three WCAG levels of conformance - A, AA, and AAA, each with its own set of success criteria. The following table shows the level of conformace for each custom element in the Smart HTML Elements framework:
| Custom element | Level of conformance |
|---|---|
| Smart.Grid |  |
| Smart.Chart | |
| Smart.GanttChart | |
| Smart.DockingLayout | |
| Smart.Accordion |  |
| Smart.Badge | |
| Smart.Button | |
| Smart.Calendar | |
| Smart.Card | |
| Smart.Carousel | |
| Smart.CheckBox | |
| Smart.ComboBox | |
| Smart.ColorPanel | |
| Smart.ColorPicker | |
| Smart.DateTimePicker | |
| Smart.DropDownList | |
| Smart.DropDownButton | |
| Smart.FileUpload | |
| Smart.Gauge | |
| Smart.ListBox | |
| Smart.ListMenu | |
| Smart.MaskedTextBox | |
| Smart.Menu | |
| Smart.MultilineTextBox | |
| Smart.MultiSplitButton | |
| Custom element | Level of conformance |
|---|---|
| Smart.NumericTextBox | |
| Smart.Pager | |
| Smart.PasswordTextBox | |
| Smart.PowerButton | |
| Smart.ProgressBar | |
| Smart.QueryBuilder | |
| Smart.RadioButton | |
| Smart.RepeatButton | |
| Smart.Scrollbar | |
| Smart.Slider | |
| Smart.Splitter | |
| Smart.SwitchButton | |
| Smart.Sortable | |
| Smart.Table | |
| Smart.Tabs | |
| Smart.Tank | |
| Smart.TextBox | |
| Smart.TimePicker | |
| Smart.Toast | |
| Smart.ToggleButton | |
| Smart.Tooltip | |
| Smart.Tree | |
| Smart.Validator | |
| Smart.Window | |
Testing the Accessibility
Each custom element in Smart HTML Elements has been thoroughly tested for compliance to the web standards with a variety of tools:
Google Chrome Lighthouse
Lighthouse is an open-source, automated tool for improving the quality of web pages. It includes tests for accessibility that have been passed by Smart HTML Elements.
Firefox Accessibility Inspector
The Firefox Accessibility Inspector is a tool that provides a thorough look at the implemented accessibility features and attributes of the elements on a page. Each of the custom elements has been inspected with this tool to ensure compliance to the aforementioned standards and that the component's semantics will be correctly passed to screen readers and other assistive technology.
WebAIM Contrast Checker
WebAIM Contrast Checker checks against Web Content Accessibility Guidelines (WCAG) to ensure the contast between foreground (text) and background colors is high enough in order to enhance the experience for visually-impaired users. An example is the contrast between the Smart HTML Elements primary theme's text and background colors, which can be seen checked in the image below:
