I am building a portlet utilizing Charts builder. One of the important requirement is it need to provide accessibility according to Section 508.
Is there any sample model that I can use? Currently, the charts that I am building, when read by a screen reader, it only says "Empty Image".
Is there any best practices or tips and tricks to accomplish the accessibility issue?
By the way, I am using web experience factory 8, and has tried Accesibility Assistance builder. But the builder did not really help.
Any helps and insight is greatly appreciated.
NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
This topic has been locked.
2 replies Latest Post - 2012-11-28T15:38:02Z by DGawron
Pinned topic Accessibility - 508 compliance
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2012-11-28T15:38:02Z at 2012-11-28T15:38:02Z by DGawron
kevintap 100000QN03746 PostsACCEPTED ANSWER
Re: Accessibility - 508 compliance2012-11-27T19:30:49Z in response to hwidjajaThe Charts builder adds several tags to the page. These tags are nested as described below.
<SPAN name= "charts_chartJViewsChartHelper"> <DIV name= "charts_chartJViewsChartHelper_div"> <SPAN name= "charts_chartJViewsChartHelper_iframe"> <IFRAME...>
It may be beneficial for the purposes of screen readers to hide one of these tags from the screen reader, possibly the charts_chartJViewsChartHelper_iframe SPAN. Since the chart content is not content that can be represented in an appropriate manner through a screen reader, the use of the aria-hidden attribute may be applicable here, assuming that you have some alternate means of providing the data conveyed in the chart for users using screen readers.
You can use an Attribute Setter builder to apply the aria-hidden attribute to one or more of the tags that I've mentioned here.
The W3C states the following about the aria-hidden attribute:
Authors MAY, with caution, use aria-hidden to hide visibly rendered content from assistive technologies only if the act of hiding this content is intended to improve the experience for users of assistive technologies by removing redundant or extraneous content. Authors using aria-hidden to hide visible content from screen readers MUST ensure that identical or equivalent meaning and functionality is exposed to assistive technologies.
See also: http://www.w3.org/TR/wai-aria/states_and_properties#aria-hidden
It may also be worthwhile to contact IBM ILOG JViews support for additional information or recommendations on how to handle the accessibility requirements with the ILOG JViews generated charts.
The postings on this site are my own and do not necessarily represent the positions, strategies, or opinions of IBM.
DGawron 10000054HC580 PostsACCEPTED ANSWER
Re: Accessibility - 508 compliance2012-11-28T15:38:02Z in response to kevintapThe part about "...MUST ensure that identical or equivalent meaning and functionality is exposed to assistive technologies." is important here. What that means is you need to provide the chart data in a form that screen readers can handle. For example, with a pie chart you would aria-hide the graphic and also provide an HTML table that lists each slice with its label and percentage in descending order. The HTML table would not be visually displayed, but would be visible to the reader. An alternative would be to profile your portlet so that either the chart is displayed or the HTML table is displayed, but not both. The version of a portlet rendered for a user is selected based upon their preferences. This way you don't need to mess with aria-hidden and the page will contain only the content appropriate to the user's stated abilities which will help reduce server load, page response times, and render time in the browser.
One more point is worth mentioning. The Accessibility builder can only automate a very small portion of the work that is required to make a portlet accessible. Accessibility requires careful thought, design, and implementation. WEF features and builders give you many ways to approach the task, but you still need to think about accessibility up-front and plan your development accordingly.