|
|
When writing the markup for a portlet, consider how people with disabilities will access the portlet. For example, people with sight limitations might not be able to distinguish certain colours or require the assistance of a reader to access the content of your portlet. You can obtain more about accessibility guidelines at the Center for Applied Special Technology (CAST) or W3C Web Accessibility Initiative.
This document proposes a short list of basic accessibility guidelines for the SPP Technical Team. It is intended to help them in producing XHTML, WML, and any other web-related markup fragments, which can be used by people with disabilities.
1.1. Because XHTML code fragments are embedded into other code fragments, make sure that they are complete, contain no open tags, and only contain valid XHTML (the same principle is applied to WML, or other valid W3C fragment). This helps to prevent the portlet's XHTML code from corrupting the portal's aggregated XHTML code.
1.2. You should make use of the portal framework CSS technology for display and presentation purposes. Thus, you should generate markup that invokes the generic style classes for portlets, rather than using tags or attributes to specify colours, fonts, or other visual elements.
1.3. When creating XHTML markup, it is recommended to use a validation tool, such as the W3C HTML Validation Service or a tool from a markup editor, such as http://www.htmlvalidator.com.
1.4. Do not use deeply nested tables as they make performance slower on Netscape browsers. Also avoid lengthy, complex XHTML and frames.
1.5. Do not create fixed-width XHTML tables in portlets as there is no way of knowing how wide a column your portlet has.
1.6. Check portlet behavior when the default browser font is changed; your portlet should handle these situations seamlessly.
1.7. Make sure any Javascript provided by a portlet does not interfere with the properties of the portal page, browser window, or other portlets on the page. Consider using some of the JSP tag libraries provided by the container to prevent Javascript function and variable name conflicts with other portlets on the portal page.
2.1 Use the alt="text" attribute to provide text equivalents for images. Use alt="" for images that do not convey important information or convey redundant information.
2.2. Graphs and Charts. Summarize the content of each graph and chart, or use the longdesc attribute to link to the description or data.
2.3. Applets, Plug-ins, and non-HTML content. When an applet, plug-in or other application is required to be present, provide a link to one that is directly accessible, or provide alternate content for those which are not directly accessible.
2.4. In general make use of images and multimedia only when they are really necessary and essential
3.1. Labels must be explicitly associated with the FORM elements through XHTML markup in order to guarantee that "assistive" technologies can communicate the purpose of the form element to the user. Although some form controls, such as submit buttons, are automatically associated with a label, other form controls (text fields, check boxes and radio buttons) do not have implicit labels. If the labels for these controls follow conventions and are positioned immediately to the left of the control or immediately above the control, then assistive technology might be able to determine the intent as conveyed by proximity. However, to ensure the label is explicitly available to assistive technology, you should use the LABEL element to specify labels for controls that do not have implicit labels.
4.1. Since scripting is useful in many cases (e.g. JavaScript mouse-overs used for visual effects), the approach to making scripting accessible is to make the functionality of scripts accessible from the keyboard (device independent) and the information (content) available to the "assistive" technology.
4.2. Don't use non-essential scripts (if the essential tasks of the web site can be accomplished with scripting turned off, then the scripting is consider non-essential.)
4.3. Ensure that there are "regular" links as an alternative for links that can only be activated by an event handler.
4.4. If the functionality and information affected by scripts is difficult to make directly accessible, then the NOSCRIPT element is one possible technique used to provide an equivalent alternative. Besides alternative content, the NOSCRIPT element can also contain a link to an alternative Web page with equivalent content and functionality.
5.1. Web pages should be readable without requiring style sheets.
5.2. Ensure that all information conveyed with colour is also conveyed in the absence of colour.
5.3. Avoid causing content to blink, flicker, or move.
5.4. When a timed response is required (e.g. a long xsearch process), alert the user, and give sufficient time to indicate a waiting time is required.
5.5. After a portlet's output template has been created, check the output to ensure that it complies with accessibility requirements. You can use Lynx (to test if the text content is available to "assistive" technologies such as screen readers), Bobby or the Advanced Internet Options of MS IE.