Accessibility Overview
We want our products to be fully experienced by the widest number of users including disabled users.
We take accessibility pretty seriously and spent a couple of iterations on it. By adhering to standards like WAI-ARIA, and Section 508 we create accessible products that can be used well together with an assistive technology, like a screen reader.
Since the technology has evolved, nowadays not only basic text-driven experiences have to be made accessible, but also other features.
Section 508
Section 1194.21 Software applications and operating systems
The following table shows the level of support that Mobiscroll provides for the Section 1194.21
| Criteria | Supporting features | Remarks |
|---|---|---|
| (a) When software is designed to run on a system that has a keyboard product functions shall be executable from a keyboard where the function itself or the result of performing a function can be discerned textually. | Supported | Native html keyboard support kept where relevant, custom key bindings added where needed |
| (b) Applications shall not disrupt or disable activated features of other products that are identified as accessibility features where those features are developed and documented according to industry standards. Applications also shall not disrupt or disable activated features of any operating system that are identified as accessibility features where the application programming interface for those accessibility features has been documented by the manufacturer of the operating system and is available to the product developer. | Supported | Mobiscroll does nothing to disrupt or disable activated accessibility features |
| (c) A well-defined on-screen indication of the current focus shall be provided that moves among interactive interface elements as the input focus changes. The focus shall be programmatically exposed so that assistive technology can track focus and focus changes. | Supported | In some cases the browser’s native focus indicator styling is overwritten with custom styling |
| (d) Sufficient information about a user interface element including the identity operation and state of the element shall be available to assistive technology. When an image represents a program element the information conveyed by the image must also be available in text. | Supported | Using WAI-ARIA,roles and attributes where applicable |
| (e) When bitmap images are used to identify controls status indicators or other programmatic elements the meaning assigned to those images shall be consistent throughout an application’s performance. | Not Applicable | |
| (f) Textual information shall be provided through operating system functions for displaying text. The minimum information that shall be made available is text content text input caret location and text attributes. | Not Applicable | |
| (g) Applications shall not override user selected contrast and color selections and other individual display attributes. | Not Applicbale | |
| (h) When animation is displayed the information shall be displayable in at least one non-animated presentation mode at the option of the user. | Not Applicable | |
| (i) Color coding shall not be used as the only means of conveying information indicating an action, prompting a response or distinguishing a visual element. | Not Applicable | |
| (j) When a product permits a user to adjust color and contrast settings a variety of color selections capable of producing a range of contrast levels shall be provided. | Not Applicable | |
| (k) Software shall not use flashing or blinking text, objects, or other elements having a flash or blink frequency greater than 2 Hz and lower than 55 Hz. | Supported | No flashing or blinking elements are used |
| (l) When electronic forms are used, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues. | Supported | Mobiscroll Forms are accessible to assistive technologies |
Section 1194.22 Web-based intranet and Internet information and applications
The following table shows the level of support that Mobiscroll provides for the Section 1194.21
| Criteria | Supporting features | Remarks |
|---|---|---|
| (a) A text equivalent for every non-text element shall be provided (e.g., via “alt", “longdesc", or in element content). | Supported | |
| (b) Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation. | Not Applicable | No multimedia is used |
| (c) Web pages shall be designed so that all information conveyed with color,is also available without color for example from context or markup. | Supported | |
| (d) Documents shall be organized so they are readable without requiring an associated style sheet. | Not fully supported | We’re providing an UI Framework for styling content. Removing style sheets doesn’t make sense |
| (e) Redundant text links shall be provided for each active region of a server-side image map. | Not Applicable | No image maps are used |
| (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 | No image maps are used |
| (g) Row and column headers shall be identified for data tables. | Not Applicable | No data tabels are used |
| (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. | Not Applicable | No data tabels are used |
| (i) Frames shall be titled with text that facilitates frame identification and navigation. | Not Applicable | No frames are used |
| (j) Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz. | Supported | No flashing or blinking elements are used |
| (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. The content of the text-only page shall be updated whenever the primary page changes. | Not Applicable | The developer is responsible for providing text-only content for pages that use Mobiscroll |
| (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. | Supported | Mobiscroll provides keyboard navigation support and screen reader support (via ARIA attributes) |
| (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). | Not Supported | |
| (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 including all directions and cues. | Supported | Mobiscroll Forms are accessible to assistive technologies |
| (o) A method shall be provided that permits users to skip repetitive navigation links. | Not Applicable | |
| (p) When a timed response is required the user shall be alerted and given sufficient time to indicate more time is required. | Not Applicable |
WAI-ARIA Support
WAI-ARIA is a World Wide Web Consortium specification that was designed to be a framework for web developers. This can be used in developing applications that leverage Ajax, scripting and other so called “rich application" techniques. This framework has clear specifications about steps that developers can use in order to make their applications more accessible to assistive technologies.
WAI-ARIA’s role is to fill the gap between rich applications and disabled users by using additional metadata with the help of HTML element attributes that screen readers can use to reason about a control or DOM element. These attributes, like role, aria-haspopup, aria-selected and others provide vital information to screen readers, which can then be used to provide a richer level of interaction with applications and websites.
Here is the complete list of WAI-ARIA attributes used by Mobiscroll:
role="dialog"for popups and pickersrole="grid"for calendar viewrole="row"for calendar view rowsrole="gridcell"for calendar views cellsrole="listbox"for scroller wheelsrole="option"for scroller wheel itemsrole="button"for button controlsaria-livefor announcementsaria-hiddenfor elements which are not visible and should not be read by screen readersaria-labelfor controls without text or icon buttonsaria-selectedfor indicating selected value on wheels and calendar daysaria-multiselectablefor multiple selectaria-disabledfor disabled items (wheel items, buttons, calendar days)
Keyboard Support
Mobiscroll ensures that your users can access the full capabilities of widgets using just the keyboard.
The following keyboard bindings are used by Mobiscroll:
- Popup
- Datepicker
- Eventcalendar
- Select
- Forms:
Tab,Shift + Tabto navigate between form elements,Spaceto press buttons,Up,Down,Left,Rightarrows to change the selected segmented item.
Support Right-To-Left (RTL) Languages
Only a few languages in the world use RTL text direction, but these languages cover over a billion people.
Beside it’s internationalization characteristic RTL is about making user experiences more accessible for users working in Right-to-left languages like, so we are considering this as an accessibility feature as well.
Mobiscroll supports RTL for every component, which can be activated with the rtl: true setting.