Accessibility

Our policy on web accessibility requires that all pages be at least minimally accessible to our visitors with disabilities.

Our definition of minimal accessibility is based upon the W3C’s Web Content Accessibility Guidelines (WCAG), which defines three levels of checkpoint priority. This policy requires at least single-A WCAG compliance, which means all priority one checkpoints.

In addition, we may establish other accessibility requirements beyond single-A compliance on a case-by-case basis. These will be documented here as well.

Accessibility features of this website:

1. Provide text equivalents for non-text elements.

The ALT attribute must be used on all images and imagemap AREAs. LONGDESC should be used for images that convey information beyond simply raw text — such as an organization chart or a data graph. Text equivalents must be provided for all multimedia files indicating what information is contained in the multimedia file. Transcripts may or may not be required, depending on the content type; if used, transcripts or captions should be synchronized (e.g. with SMIL).
[WCAG 1.1, 1.3, 1.4]

2. Don’t rely solely upon color.

The use of colored text or images to convey information is encouraged, but this must not be the only way in which that information is conveyed. Use context or additional markup as well as pure color changes. For example, if indicating strong emphasis with the color green, also use the element.
[WCAG 2.1]

3. Identify language changes.

Screenreaders and other assistive technologies have different libraries for different languages. A French phrase pronounced according to English “rules” may lose all meaning. Use the LANG attribute (and likely the SPAN element) to identify a language change, such as Cette phrase est en fran├žais.
[WCAG 4.1]

4. Make sure pages are usable without style sheets.

Our web page templates rely heavily upon stylesheets for visual presentation, and use of CSS is highly encouraged. However, older browsers and many adaptive technology browsers may not support stylesheets, so it’s important to make sure that the pages can still be used without CSS. For example, if CSS is used to position elements on a page, those elements might appear visually in one order using CSS, and out of order if CSS is turned off. You can test this by using a non-CSS browser or by turning off CSS in your browser and seeing if the page is still usable.
[WCAG 6.1]

5. Update equivalents for generated content.

If a page is autogenerated in some way, the textual equivalents for that page should be in synch with the visually oriented content.
[WCAG 6.2]

6. Don’t make the screen flicker.

Flashing or strobing screen effects can trigger seizures in people with photosensitive epilepsy. These kinds of effects should never be found on Guild pages.
[WCAG 7.1]

7. Use plain, understandable English.

Our website pages should be understandable by anyone, including people with cognitive disabilities, poor readers, younger readers, and those for whom English is not their primary language. Jargon and technical terms should be defined when first used or a glossary/reference link provided, if the meaning is not clear from context.
[WCAG 14.1]

8. Use client-side imagemaps, not server-side.

Client-side imagemaps are supported by all current browsers and have many accessibility benefits when used appropriately. Server-side imagemaps may be used in addition to client-side maps, but should never replace them. A text equivalent list of links should be provided for all imagemaps.
[WCAG 9.1, 1.2]

9. Use HTML 4.0 table markup on data tables.

For tables that express tabular information — content laid out in columns and rows — use HTML 4.0′s features that associate cell content with column and row headers. For more on this, see the HTML 4.0 Specification.
[WCAG 5.1, 5.2]

10. Frames should have NOFRAMES and TITLEs.

Our pages should avoid using frames whenever possible. If frames are used, a valid NOFRAMES element should be set, and each frame within the frameset should have the TITLE attribute set. For example, “Navigation Links”, “Current Document” and “Help Functions” as titles in a theoretical three-panel frameset.
[WCAG 12.1]

11. Don’t rely solely upon scripts and applets.

Not everyone will be able to execute a javascript/ECMAscript script or a java applet. For this reason, alternatives need to be provided and scripts should still be usable when javascript is disabled. For example, if a script verifies form input before sending, using javascript, the form should still function when the user is unable to use to javascript (or has it disabled purposely), and the server should still perform input field verification. If a script or applet can’t be made accessible, an alternate way to perform the same function should be created.
[WCAG 6.3]

12. As a last resort, make an alternate page.

Alternate text pages should rarely, if ever, be necessary. If you find some rare circumstance in which you can’t make a page that degrades gracefully, you should consider creating a second version of that page. This is dangerous because alternate pages have a tendency to get out of synch with the “inaccessible” page very quickly. Also, because the HTML standards are backwards-compatible and forwards-accessible, there should be no need in all but the most extreme cases for an alternate page. Therefore, alternate pages should be avoided on Guild sites.
[WCAG 11.4]