Accessibility

Web accessibility refers to the inclusive practice of removing barriers that prevent access to websites by people with disabilities.

There are a few different standards on what a web site or in Vaadin’s case a web application should implement and comply with in order to make it usable by assistive devices but also in order for people with color blindness to be able to get the information they need. The two most notable standards are that of the World Wide Web Consortium (W3C) aka. the WAI-ARIA 1.1 Authoring Practices and the US Rehabilitation Act aka. the 508. These standards set the groundwork for the minimum requirements for an accessible website and Vaadin follow these standards as closely as possible.

Vaadin has extensive support for the WAI-ARIA standard by supporting the standard ARIA-attributes and helping the application developer in building an application that not only complies with the standard but also out-of-the-box gives more value than a standard alone can deliver.

Developing an accessible software should be always done with continuously testing the software e.g. using screen readers. Vaadin development team tests the framework using JAWS, NVDA and VoiceOver.

508 Standard | Part 1 Vaadin
(a) A text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content).

Every image, applet, embedded media, plug-in, etc. that conveys content has equivalent alternative text (alt, longdesc, or in the element context).

True for Vaadin AbstractEmbedded (i.e. image, iframe and flash) and e.g. Buttons with icons.

The alternative text succinctly describes the content conveyed by the element, without being too verbose (for simple objects) or too vague (for complex objects).

The text content is up to the application itself. Vaadin components support adding an alternative text.

Complex graphics (graphs, charts, etc.) are accompanied by equivalent text, either through a description in the body of the page, a link to a description on a separate page, and/or the longdesc attribute. [See Note 1]

The text content is up to the application itself. Vaadin components support adding an alternative text.

Images that have a function (images within links, image buttons, and image map areas) have alternative text which describes the associated function.

The text content is up to the application itself. Vaadin components support adding an alternative text.

Decorative graphics are CSS background images or have null/empty alt values (alt=""). Images with text alternatives in element content are given empty alt text to avoid redundancy.

Up to the application itself. Vaadin’s default themes.

Transcripts are provided for audio content.

The Vaadin Audio component supports ALT texts. Other transcripts possible to do with standard Vaadin Labels.

(b) Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation

Video files and live audio broadcasts have synchronized captions.

<track> tag for <video> is missing from Vaadin. This can however be done through your choice of media player.

Content presented through video, but not through audio is provided in an audio description track.

Vaadin as a web UI framework doesn't concern itself with your choice of Audio/video playback. Vaadin doesn't do anything to prevent you from achieving this.

(c) Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.

Color is not used solely to convey important information.

Up to the theme developer. Possible to create various themes for Vaadin applications and select theme on sign in.

Sufficient contrast is provided.

Up to the theme developer. Possible to create various themes for Vaadin applications and select theme on sign in.

(d) Documents shall be organized so they are readable without requiring an associated style sheet.

Style sheets may be used for layout, but the document is still readable and understandable (even if less visually appealing) when the style sheet is turned off.

Screen readers are still able to read the content without the stylesheets thanks to WAI-ARIA attributes defined for all components. For more information see the wiki.

(e) Redundant text links shall be provided for each active region of a server-side image map.

Client-side image maps are used instead of server-side image maps. Appropriate alternative text is provided for the image as well as each hot spot area.

Vaadin does not use server-side image maps. Instead e.g. the ImageMap addon supports the creation of client-side image maps. See the image map widget.

(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

Vaadin does not use server-side image maps. Instead e.g. the ImageMap addon supports the creation of client-side image maps. See the image map widget.

(g) Row and column headers shall be identified for data tables.

Data tables have column and/or row headers appropriately identified (using the <th>element).

Vaadin Grid supports this.

Tables used strictly for layout purposes do NOT use the <th>element.

Vaadin does not use Tables for layouting.

(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.

Data table cells are associated with the appropriate headers using the scope or id/headers attributes.

Vaadin Grid supports this.

(i) Frames shall be titled with text that facilitates frame identification and navigation.

Each frame is given a title that describes the frame's purpose or content.

The frame/iframe gets an ALT text but not a title attribute.

(j) Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz

No element on the page flashes at a rate of 2 to 55 cycles per second, thus reducing the risk of optically-induced seizures.

Vaadin does not have by default anything that flickers.

(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.

A text-only version is created only when there is no other way to make the content accessible or when it offers significant advantages over the main version for certain disability types.

Vaadin applications can be made accessible without text-only versions. However, if the need should arise this is possible to do e.g. with JSP / static HTML pages.

The text-only version provides equivalent content and is up-to-date with the main version.

Can be done e.g. by having a Vaadin app and a JSP/Spring MVC app use the same backend logic.

(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.

Content and functionality provided by scripting is directly accessible to assistive technologies and the keyboard. <noscript> content does not constitute a suitable alternative to inaccessible scripting.

Vaadin applications are usable without a keyboard / mouse by using e.g. a screen reader.

(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). [See Note 2] [See Note 3].

A link is provided to a page where the plug-in can be downloaded.

Not applicable. Vaadin doesn't use or require any plugins.

All applets, scripts and plug-ins (including PDF and PowerPoint files, etc.) and the content within them are accessible to assistive technologies, or else an alternative means of accessing equivalent content is provided.

Even though Vaadin doesn't require any it does not restrict the usage of applets, scripts and plugins. The responsibility is however then on the developer.

(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.

<input>, <textarea>, and <select> elements have descriptive labels.

All built in layouts manage the labeling properly based on the components' captions. WAI-ARIA attributes are used to help assistive devices.

Scripting of form elements does not interfere with assistive technologies or keyboard.

Vaadin scripts do not interfere with assistive technologies.

(o) A method shall be provided that permits users to skip repetitive navigation links.

A link is provided to skip over navigational menus or other lengthy lists of links. A good heading structure also facilitates navigation.

Create a link that only screen readers can see. "Clicking" on the link moves the focus to a specific component with a predefined ID.

Vaadin provides a style name (v-assistive-device-only) for creating "invisible" components that can only be seen by e.g. screen readers.

(p) When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.

The user has control over the timing of content changes.

No Vaadin components require user input within a set time.


508 Standard | Part 2 Vaadin
(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.

Is possible to do with Vaadin. Using ARIA attributes, see the wiki.

(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.

Vaadin does not disrupt or disable 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.

Works with Vaadin out of the box.

(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.

Works with Vaadin out of the box. Check out the wiki.

(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.

Up to the developer

(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.

Handled by the browser

(g) Applications shall not override user selected contrast and color selections and other individual display attributes.

Vaadin does not try to override this browser feature.

(h) When animation is displayed, the information shall be displayable in at least one non-animated presentation mode at the option of the user.

Vaadin does not do any explicit animations. Up to the application developer to use CSS transformations and other animations at their own discretion.

(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.

Up to the developer

(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.

Up to the developer

(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.

Vaadin does not have by default anything that flickers.

(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.

All built in layouts manage the labeling properly based on the components' captions. WAI-ARIA attributes are used to help assistive devices.

Accessibility

Web accessibility refers to the inclusive practice of removing barriers that prevent access to websites by people with disabilities.

There are a few different standards on what a web site or in Vaadin’s case a web application should implement and comply with in order to make it usable by assistive devices but also in order for people with color blindness to be able to get the information they need. The two most notable standards are that of the World Wide Web Consortium (W3C) aka. the WAI-ARIA 1.1 Authoring Practices and the US Rehabilitation Act aka. the 508. These standards set the groundwork for the minimum requirements for an accessible website and Vaadin follow these standards as closely as possible.

Vaadin has extensive support for the WAI-ARIA standard by supporting the standard ARIA-attributes and helping the application developer in building an application that not only complies with the standard but also out-of-the-box gives more value than a standard alone can deliver.

Developing an accessible software should be always done with continuously testing the software e.g. using screen readers. Vaadin development team tests the framework using JAWS, NVDA and VoiceOver.

508 Standard | Part 1 Vaadin
(a) A text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content).

Every image, applet, embedded media, plug-in, etc. that conveys content has equivalent alternative text (alt, longdesc, or in the element context).

True for Vaadin AbstractEmbedded (i.e. image, iframe and flash) and e.g. Buttons with icons.

The alternative text succinctly describes the content conveyed by the element, without being too verbose (for simple objects) or too vague (for complex objects).

The text content is up to the application itself. Vaadin components support adding an alternative text.

Complex graphics (graphs, charts, etc.) are accompanied by equivalent text, either through a description in the body of the page, a link to a description on a separate page, and/or the longdesc attribute. [See Note 1]

The text content is up to the application itself. Vaadin components support adding an alternative text.

Images that have a function (images within links, image buttons, and image map areas) have alternative text which describes the associated function.

The text content is up to the application itself. Vaadin components support adding an alternative text.

Decorative graphics are CSS background images or have null/empty alt values (alt=""). Images with text alternatives in element content are given empty alt text to avoid redundancy.

Up to the application itself. Vaadin’s default themes.

Transcripts are provided for audio content.

The Vaadin Audio component supports ALT texts. Other transcripts possible to do with standard Vaadin Labels.

(b) Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation

Video files and live audio broadcasts have synchronized captions.

<track> tag for <video> is missing from Vaadin. This can however be done through your choice of media player.

Content presented through video, but not through audio is provided in an audio description track.

Vaadin as a web UI framework doesn't concern itself with your choice of Audio/video playback. Vaadin doesn't do anything to prevent you from achieving this.

(c) Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.

Color is not used solely to convey important information.

Up to the theme developer. Possible to create various themes for Vaadin applications and select theme on sign in.

Sufficient contrast is provided.

Up to the theme developer. Possible to create various themes for Vaadin applications and select theme on sign in.

(d) Documents shall be organized so they are readable without requiring an associated style sheet.

Style sheets may be used for layout, but the document is still readable and understandable (even if less visually appealing) when the style sheet is turned off.

Screen readers are still able to read the content without the stylesheets thanks to WAI-ARIA attributes defined for all components. For more information see the wiki.

(e) Redundant text links shall be provided for each active region of a server-side image map.

Client-side image maps are used instead of server-side image maps. Appropriate alternative text is provided for the image as well as each hot spot area.

Vaadin does not use server-side image maps. Instead e.g. the ImageMap addon supports the creation of client-side image maps. See the image map widget.

(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

Vaadin does not use server-side image maps. Instead e.g. the ImageMap addon supports the creation of client-side image maps. See the image map widget.

(g) Row and column headers shall be identified for data tables.

Data tables have column and/or row headers appropriately identified (using the &ltth>element).

Vaadin Grid supports this.

Tables used strictly for layout purposes do NOT use the <th>element.

Vaadin does not use Tables for layouting.

(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.

Data table cells are associated with the appropriate headers using the scope or id/headers attributes.

Vaadin Grid supports this.

(i) Frames shall be titled with text that facilitates frame identification and navigation.

Each frame is given a title that describes the frame's purpose or content.

The frame/iframe gets an ALT text but not a title attribute.

(j) Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz

No element on the page flashes at a rate of 2 to 55 cycles per second, thus reducing the risk of optically-induced seizures.

Vaadin does not have by default anything that flickers.

(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.

A text-only version is created only when there is no other way to make the content accessible or when it offers significant advantages over the main version for certain disability types.

Vaadin applications can be made accessible without text-only versions. However, if the need should arise this is possible to do e.g. with JSP / static HTML pages.

The text-only version provides equivalent content and is up-to-date with the main version.

Can be done e.g. by having a Vaadin app and a JSP/Spring MVC app use the same backend logic.

(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.

Content and functionality provided by scripting is directly accessible to assistive technologies and the keyboard. <noscript> content does not constitute a suitable alternative to inaccessible scripting.

Vaadin applications are usable without a keyboard / mouse by using e.g. a screen reader.

(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). [See Note 2] [See Note 3].

A link is provided to a page where the plug-in can be downloaded.

Not applicable. Vaadin doesn't use or require any plugins.

All applets, scripts and plug-ins (including PDF and PowerPoint files, etc.) and the content within them are accessible to assistive technologies, or else an alternative means of accessing equivalent content is provided.

Even though Vaadin doesn't require any it does not restrict the usage of applets, scripts and plugins. The responsibility is however then on the developer.

(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.

<input>, <textarea>, and <select> elements have descriptive labels.

All built in layouts manage the labeling properly based on the components' captions. WAI-ARIA attributes are used to help assistive devices.

Scripting of form elements does not interfere with assistive technologies or keyboard.

Vaadin scripts do not interfere with assistive technologies.

(o) A method shall be provided that permits users to skip repetitive navigation links.

A link is provided to skip over navigational menus or other lengthy lists of links. A good heading structure also facilitates navigation.

Create a link that only screen readers can see. "Clicking" on the link moves the focus to a specific component with a predefined ID.

Vaadin provides a style name (v-assistive-device-only) for creating "invisible" components that can only be seen by e.g. screen readers.

(p) When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.

The user has control over the timing of content changes.

No Vaadin components require user input within a set time.


508 Standard | Part 2 Vaadin
(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.

Is possible to do with Vaadin. Using ARIA attributes, see the wiki.

(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.

Vaadin does not disrupt or disable 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.

Works with Vaadin out of the box.

(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.

Works with Vaadin out of the box. Check out the wiki.

(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.

Up to the developer

(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.

Handled by the browser

(g) Applications shall not override user selected contrast and color selections and other individual display attributes.

Vaadin does not try to override this browser feature.

(h) When animation is displayed, the information shall be displayable in at least one non-animated presentation mode at the option of the user.

Vaadin does not do any explicit animations. Up to the application developer to use CSS transformations and other animations at their own discretion.

(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.

Up to the developer

(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.

Up to the developer

(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.

Vaadin does not have by default anything that flickers.

(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.

All built in layouts manage the labeling properly based on the components' captions. WAI-ARIA attributes are used to help assistive devices.