Accessibility
Generating Accessible Markup
Web Site Accessibility is about making content available to as many users as possible, regardless of the technology used. Accessible Web pages benefit everyone, since they tend to download and display faster, are easier to read and easier to navigate. Web content generated by XStandard is ideal for the new generation of accessibility devices, because it generates XHTML (Strict or 1.1) code. XHTML Strict/1.1 complies with Web Content Accessibility Guidelines (WCAG) developed by W3C - the same body that oversees the XHTML standard itself. W3C guidelines enjoy wide government support and are reference points for public sector accessibility initiatives such as Section 508 provisions in the United States and Common Look And Feel (CLF) requirements in Canada.
Below is a partial list of XStandard features that help generate more accessible code.
Removing The "Noise" From Markup
Deprecated tags, badly formed markup and the fusing together of content and presentation hinder the processing of content by assistive technologies. XStandard eliminates markup "noise" of this type by generating clean, well-formed code and by completely separating content from presentation. Formatting is only permitted using external or embedded CSS.
Headings (<h1> to <h6>) are probably the most important markup for making content accessible because they help users of assistive technologies navigate Web pages. When content authors are presented with WYSIWYG editors that contain font selectors and color pickers, formatting is used instead of headings. For example, instead of semantic markup like this:
<h2>Annual Report</h2>
Font selectors and color pickers generate markup "noise" like this:
<font size="4"><span style="font-family:Times;color:red">Annual Report</span></font>
To avoid the creation of markup "noise", XStandard employs a Styles Menu. The Styles Menu offers content creators a choice of formatting styles that can be given friendly labels that ensure authors apply the correct markup to content. A screen shot of the Styles menu is shown below.
Encouraging Correct Use Of Markup
Many WYSIWYG editors incorrectly use the <blockquote> tag for indenting. This hinders accessibility because it sends the wrong message to assistive technologies. <blockquote> should only be used for quotations and indents should be implemented through CSS. The screen shot below shows how XStandard differentiates between block quotes and indents and encourages content creators to use the correct markup for the job.
Use Of Relative Units Of Length
Most browsers allow users to control the size of text displayed on the Web page, but this feature only works if relative units of measure are used in creating Web page content in the first place. XStandard supports both the em and % units of length.
Decorative Versus Non-decorative Images
Images enhance the visual experience of those who are sighted, but for those with disabilities that limit vision, for users of small screen mobile devices with limited display areas, or for search engine applications, alternate text are an important replacement for images.
There are two types of images: decorative and non-decorative (also known as informative images). Incorrect use of one or the other can lead to distortions in the meaning of content. Informative images transmit semantic meaning to devices such as accessibility screen readers and so require alt text. By contrast, decorative images (such as spacers, bullets, borders, etc.) are merely "eye-candy", convey no semantic meaning at all, and should not therefore use alt text. To make decorative images invisible to non-visual devices, the setting should be alt="".
The example below shows alt text used incorrectly for decorative images. Listen to the sound file to hear the confusion this creates when the markup is processed by an auditory user-agent such as a screen reader:
<p>Ingredients for black bean soup:<br /><img src="redball.gif" alt="Red ball" />Vegetable broth<br /><img src="redball.gif" alt="Red ball" />Black beans<br /><img src="redball.gif" alt="Red ball" />Crushed tomatoes</p>
To avoid such mistakes, the screen shot below shows how XStandard prompts the author to identify an image as decorative or non-decorative. The editor then goes on to require Alternate text for all non-decorative images and also permits authors to enter a Description (tooltip) and a Long description URL.
If the image is identified as decorative, data is removed from Alternate text, Description and Long Description URL fields. These controls are then disabled, since decorative images cannot have alternate text, tooltips or long descriptions (see below).
Data Tables Versus Layout Tables
In XHTML, tables are used for visual layout (layout tables), or for displaying data (data tables). Incorrect use of tables can make content in tables meaningless to assistive technologies. Below is an example of a data table, where the data in the table can only be understood in relation to column and/ or row headers.
Cups of coffee consumed by each person| Name | Cups | Type | Sugar |
|---|
| Wendy | 10 | Regular | yes |
| Jim | 15 | Decaf | no |
If the markup behind this table does not associate each cell with the appropriate header, the cells will be processed like <div> tags by non-visual devices. Listen to how an auditory user-agent "reads" the table whose markup is incorrect. Now listen to the same table using correct markup.
XStandard makes it easy to use the right type of table for the right job. When users of XStandard create tables, they can explicitly select the type of table required (data table or layout table), as shown in the screenshot below:
Identifying row and column headers is made easy, thanks to the pop-up menu seen in the screenshot below.
Abbreviations
Abbreviation tags help auditory devices such as screen readers to correctly pronounce abbreviated words and to render the expanded version of abbreviations. The expanded version of the word is placed in the title attribute as shown in these examples.
<abbr title="World Wide Web Consortium">W3C</abbr><abbr title="Manufacturer">Mfr.</abbr><abbr title="5 5 5 - 1 2 3 4">555-1234</abbr>
XStandard makes it easy to use abbreviations and acronyms and even prompts authors to enter the "Full Text" for the title attribute, as shown in the screenshot below.
The use of "Full Text" for abbreviations and acronyms can better convey the meaning of content to users of assistive technologies. But overuse of "Full Text" can become annoying. Following best practices, XStandard therefore prompts for "Full Text" only if there is no "Full Text" entered elsewhere for a given abbreviation.
Screen Reader Preview
The Screen Reader Preview feature which is activated by pressing 
on the toolbar displays content in the linear manner in which screen readers process content. It causes authors to consider accessibility when contributing content and encourages them to correct commonly made mistakes that might hinder accessibility.
When authors manage content through XStandard's WYSIWYG interface, the editor automatically makes it impossible to commit errors in coding that hamper accessibility (such as using deprecated tags for example), or to make errors of omission (such as forgetting to supply a table Summary). However, if content is entered through "View Source", XStandard catches accessibility errors through the Screen Reader Preview.
Sample error reports include:
This document contains an <b> tag. It is better to use <strong>.
This document contains an <i> tag. It is better to use <em>.
"The alt text for this image is missing."
"The summary text for this table is missing."
The Screen Reader Preview feature is written in XSLT and can be customized or completely replaced by a specialized version. For instance, XStandard ships with built-in warnings against using ambiguous hyperlink text such as Click Here, but the XSLT can be customized to modify such expressions or to add new ones.
Interface Accessibility
Keyboard Accessible Interface
XStandard is fully keyboard accessible.
This makes it possible to edit even complex constructs such as definition lists. The screen shot below shows editing of definition lists using the keyboard.
The editor's toolbar is also keyboard accessible via the context menu, as seen in the screen shot below.
Keyboard Shortcuts
| Press | To |
|---|
| CTRL + A | Select all. |
| CTRL + LEFT ARROW | Move cursor to the beginning of the current or previous word. |
| SHIFT + CTRL + LEFT ARROW | Select text by words. |
| CTRL + RIGHT ARROW | Move cursor to the beginning of the next word. |
| SHIFT + CTRL + RIGHT ARROW | Select text by words. |
| CTRL + UP ARROW | Move cursor to the beginning of the current or previous paragraph or table cell. |
| CTRL + DOWN ARROW | Move cursor to the beginning of the next paragraph of table cell. |
| HOME | Move cursor to the beginnng of the line. |
| CTRL + HOME | Move cursor to the top of the document. |
| END | Move cursor to the end of the line. |
| CTRL + END | Move cursor to the bottom of the document. |
| SHIFT + (mouse click or arrow key or HOME or END) | Select or extend the selection. |
| PAGE UP | Page up. |
| PAGE DOWN | Page down. |
| TAB | Move focus to previous control on the form. This feature is suppored in most desktop develpment environments and IE. |
| SHIFT + TAB | Move focus to next control on the form. This feature is suppored in most desktop develpment environments and IE. |
| CTRL + I | Apply/remove emphasis markup on selected text. |
| CTRL + B | Apply/remove strong emphasis markup on selected text. |
| CTRL + K | Bring up the hyperlink properties dialog box when text is selected. |
| F7 | Check spelling. |
| SHIFT + ENTER | Insert line break. |
| CTRL + Z | Undo last action. |
| SHIFT + F10 | Display context menu. |
| ESC | Cancel the current task. |
| DELETE | Delete selected object. |
| CTRL + X | Cut |
| CTRL + C | Copy |
| CTRL + V | Paste |
| SHIFT + DELETE | Cut |
| CTRL + INSERT | Copy |
| SHIFT + INSERT | Paste |
Compliance With Accessiblity Guidelines
Section 508 (USA)
What are Section 508 accessibility requirements?
Section 508 of the U.S. Rehabilitation Act1 requires federal agencies take appropriate steps to ensure electronic and information technology is accessible to people with disabilities. Since WYSIWYG editors are regularly used by public sector authors to input and manage content, incorporating a tool such as XStandard into content management systems is a significant step towards compliance.
Section 508 includes 16 accessibility requirements relating to Web-based content. Of the 16 requirements, 11 are "Priority 1" checkpoints2 found in the "Web Content Accessibility Guidelines" developed by W3C3.
How do Section 508 requirements compare to Canadian accessibility requirements?
Canadian government accessibility requirements are considered to be stricter than those in the U.S. and include all Priority 1 and Priority 2 checkpoints found in the "Web Content Accessibility Guidelines" developed by W3C (see "CLF - Canada" from the left-hand menu for more details).
Vendors whose products satisfy both U.S. and Canadian accessibility requirements are clearly better placed to secure and retain public sector clients in both countries.
How does XStandard fulfill North American accessibility requirements?
XStandard's performance in terms of U.S. and Canadian accessibility requirements is exemplary, for the simple reason that XStandard is the first WYSIWYG editor to output code that is XHTML 1.1 compliant. XHTML 1.1 was after all designed by the same body that formulated the accessibility standards referenced in Section 508 and Canada's CLF requirements - W3C.
XHTML 1.1 is ideal for meeting accessibility requirements because it suppresses deprecated markup, makes the use of CSS for formatting compulsory and totally separates content from presentation. By contrast, when native HTML or RTF editors are used, clean up tools are required to remove the mistakes and "noise" that impede accessibility. This process is expensive and time-consuming. In addition, clean-up tools can themselves generate bad code, or simply suppress formatting tags they do not recognize.
Section 508 Accessibility Requirements Applicable To A WYSIWYG Editor4 - How XStandard Measures Up| Support | Priority 1 W3C Checkpoints | How XStandard Measures Up |
|---|
| Yes | 1.1 - Text equivalents: "Provide a text equivalent for every non-text element (e.g., via alt, longdesc, or in element content." | (1) User is required to provide alt text before an image can be inserted. (2) When setting up a library of images, alt texts can be associated with images so when users select an image the alt text is automatically populated. (3) Future release will include method to make it easier for business users to enter content for longdesc. |
| Yes | 5.1 - Table headers: "For data tables, identify row and column headers." | The editor supports <th> and makes it easy for users to convert data cells to headers. |
| Yes | 5.2 - Table structure: "For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells." | The editor supports <thead>, <tbody>, <tfoot> and the headers attribute. |
| Yes | 6.1 - Order style sheets: "Organize documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document." | By displaying the editor's content without CSS formatting, the Screen Reader Preview gives users the opportunity to verify content can be understood without styles. |
| No | 9.1 - Client-side image maps: "Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape." | The editor does not support image maps at this time. |
What is Common Look and Feel (Canada)
What are Common Look and Feel (CLF) requirements?
The Canadian Treasury Board designed CLF standards and guidelines5 in order to visually unify thousands of Government of Canada (GoC) Web sites and to ensure all Canadians have equal access to information on those sites. Developers are now required to meet CLF requirements when building GoC Web sites. Vendors whose solutions facilitate compliance are therefore better placed to secure and retain public sector clients at the federal, provincial and municipal levels.
Which CLF standards apply to content management tools like XStandard?
XStandard is a WYSIWYG editor that would typically be incorporated into a browser-based content management solution. Most public sector content authors regularly use WYSIWYG editors to input and manage content online.
Output from WYSIWYG editors should therefore meet CLF requirements on 3 levels6:
- Official Languages
- Formatting
- Accessibility
Official Languages
XStandard applies the Unicode standard to permit authoring of content in any language and ships with English, French, Spanish, Dutch, Italian and Chinese versions of its interface. The editor's localization feature makes it easy to modify the standard language interfaces and to create additional language versions as necessary (German, Russian, etc.).
Formatting
CLF guideline 6.1 requires GoC Web sites to use Cascading Style Sheets (CSS) for formatting, in order to achieve consistent presentation of content. XHTML 1.1 is the first W3C standard to force the total separation of content from presentation and to compel formatting exclusively through CSS. XStandard's adoption of the XHTML 1.1 standard therefore ensures authors meet CLF formatting requirements while the editor's intuitive drop-down "styles" menu makes it easy for public sector content authors to apply CSS in support of those standards.
CLF validating standard 6.8 requires developers to assess the accessibility status of Web sites. XStandard's built-in validator Screen Reader Preview displays a linear view of content managed through the editor, as a screen reader sees it. This allows authors to assess the accessibility of content as they are contributing it.
Accessibility
CLF accessibility standards are in fact based on 14 guidelines developed by W3C7. Each guideline indicates actions that Web page authors must perform to meet the requirements of the guideline. These actions are called "Checkpoints".
Treasury Board requires developers to comply with all Priority 1 and Priority 2 checkpoints8.
Though meeting CLF accessibility requirements is challenging, the table below shows XStandard's level of compliance to be exemplary. It is also unmatched, for the simple reason that XStandard is the first WYSIWYG editor to output code that is XHTML 1.1 compliant. XHTML 1.1 was after all designed by the same body that formulated the accessibility standards referenced by CLF guidelines - W3C.
The suppression of deprecated markup, the compulsory use of CSS for formatting and the total separation of content from presentation all make XHTML 1.1 ideal for meeting accessibility requirements. By contrast, when native HTML or RTF editors are used by public sector authors, "dirty" code is generated and clean up tools are required to remove the mistakes and "noise" that impede accessibility. This process is expensive and time-consuming. In addition, clean-up tools can themselves generate bad code, or simply suppress formatting tags they do not recognize.
CLF Accessibility Requirements Applicable To A WYSIWYG Editor - How XStandard Measures Up| Support | Priority 1 And 2 W3C Checkpoints | How XStandard Measures Up |
|---|
| Yes | 1.1 - Text equivalents: "Provide a text equivalent for every non-text element (e.g., via alt, longdesc, or in element content." | (1) User is required to provide alt text before an image can be inserted. (2) When setting up a library of images, alt texts can be associated with images so when users select an image the alt text is automatically populated. (3) Future release will include method to make it easier for business users to enter content for longdesc. |
| Yes | 1.2 - Valid documents: "Create documents that validate to published formal grammars." | Content validates to XHTML Strict / 1.1 |
| Yes | 3.3 - Style sheets: "Use style sheets to control layout and presentation." | Formatting is done exclusively through CSS. |
| Yes | 3.4 - Units: "Use relative rather than absolute units in markup language attribute values and style sheet property values." | The editor supports both em and % units of length. |
| Yes | 3.5 - Headings: "Use header elements to convey document structure and use them according to specification." | The editor supports all header elements: <h1> to <h6> |
| Yes | 3.6 - Lists: "Mark up lists and list items properly." | The editor supports <ol>, <ul> and <dl>. |
| Yes | 3.7 - Quotations: "Mark up quotations. Do not use quotation markup for formatting effects such as indentation." | The editor makes it easy to apply CSS for indentation. |
| Yes | 4.1 - Natural Languages: "Clearly identify changes in the natural language of a document's text and any text equivalents (e.g., captions)." | The editor supports xml:lang. |
| Yes | 5.1 - Table headers: "For data tables, identify row and column headers." | The editor supports <th> and makes it easy for users to convert data cells to headers. |
| Yes | 5.2 - Table structure: "For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells." | The editor supports <thead>, <tbody>, <tfoot> and the headers attribute. |
| Yes | 5.3 - Avoid tables for layout: "Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linearized version)." | The Screen Reader Preview gives the users the opportunity to verify the linear version of the layout table makes sense. |
| Yes | 5.4 - Avoid tables for formatting: "If a table is used for layout, do not use any structural markup for the purpose of visual formatting." | The Screen Reader Preview gives the user the opportunity to verify they are using a layout table correctly. |
| Yes | 6.1 - Order style sheets: "Organize documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document." | By displaying the editor's content without CSS formatting, the Screen Reader Preview gives users the opportunity to verify content can be understood without styles. |
| No | 9.1 - Client-side image maps: "Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape." | The editor does not support image maps at this time. |
| Yes | 11.1 - W3C technologies: "Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported." | The editor outputs XHTML Strict / 1.1 and can be customized using W3C technologies such as XML, XSLT, CSS, SOAP. |
| Yes | 11.2 - Deprecated elements: "Avoid deprecated features of W3C technologies." | The editor uses the latest spec and discourages the use of deprecated features such as <font> and the style attribute. |
| Yes | 13.1 - Link targets: "Clearly identify the target of each link." | The Screen Reader Preview validates hyperlink text and alerts business users to the use of meaningless text such as click here. |
Footnotes
- http://www.section508.gov
- Priority 1 checkpoints are requirements that Web content developers must satisfy "Otherwise, one or more groups will find it impossible to access information in the document. Satisfying this checkpoint is a basic requirement for some groups to be able to use Web documents."
- http://www.w3.org/TR/WAI-WEBCONTENT/
- Requirements not relevant to WYSIWYG editors would include features such as those relating to Web design (ex: "prevent screen flickering"), individual authoring styles (ex: "use simple language") or multimedia products (ex: "provide auditory descriptions of visual tracks").
- http://www.tbs-sct.gc.ca/clf-nsi/
- Requirements not relevant to WYSIWYG editors would include features such as those relating to Web design (ex: "prevent screen flickering"), individual authoring styles (ex: "use simple language") or multimedia products (ex: "provide auditory descriptions of visual tracks").
- http://www.w3.org/TR/WAI-WEBCONTENT/
- Priority 1 checkpoints: "A Web content developer must satisfy this checkpoint. Otherwise, one or more groups will find it impossible to access information in the document. Satisfying this checkpoint is a basic requirement for some groups to be able to use Web documents." Priority 2 checkpoints: "A Web content developer must satisfy this checkpoint. Otherwise, one or more groups will find it difficult to access information in the document. Satisfying this checkpoint will remove significant barriers to accessing Web documents."