W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > October to December 2007

Queensland University Guidelines regarding Aphasia (2nd try)

From: Christophe Strobbe <christophe.strobbe@esat.kuleuven.be>
Date: Wed, 31 Oct 2007 21:53:46 +0100
Message-Id: <6.2.5.6.2.20071031214145.02cfe430@esat.kuleuven.be>
To: <w3c-wai-gl@w3.org>

Hi,

[Please ignore my previous message; it was accidentally sent before I 
had finished it.]

I recently read the Guidelines for Web Developers by the Queensland 
University Aphasia Groups [1]. They have been available since 2001 
but as far as I can see, they haven't been discussed on this mailing list.
The guidelines are organised into three categories: content, 
layout/formatting and navigation. I will list the guidelines below, 
with my own comments preceded by "CS". (So this message becomes a 
primitive gap analysis; I hope I haven't overlooked anything.)


Content:


1. Keep the information as simple and concise as possible.

CS: This sounds very similar to WCAG 1.0 checkpoint 14.1 (Use the 
clearest and simplest language appropriate for a site's content). The 
closest equivalent in WCAG 2.0 is SC 3.1.5 (reading level) and its 
techniques, e.g. the future technique "Using the clearest and 
simplest language appropriate for the content".


2. Use short phrases and sentences, avoiding polysyllabic words.

CS: This could be covered by the technique mentioned above, although 
a separate technique would make it stand out more.


3. Use words which are in common usege rather than words which the 
reader would rarely come across.

CS: We've written a test for this in UWEM 1.2 
(<http://www.wabcluster.org/uwem1_2/>, cf. test 14.1_HTML_01), but 
"common usage" is hard to define: how "common"? (When I did a quick 
survey of dictionaries for use in primary education, I found that 
they contained definitions for 10,000 to 20,000 terms and phrases, 
which is a higher number than I expected in advance; I checked only 
Dutch, French, German, English and Spanish. I'm still looking for 
research regarding the mental lexicon of people with aphasia, dyslexia etc.)


4. Where possible use bullets and numbers to create lists of 
hyperlinks, rather than embedding links in paragraphs of text.


5. Accompany text with text equivalents e.g. graphics, sound, photos 
and use "alt.." (html) to add simple labels to images.

CS: This maps to "supplemental context" in SC 3.1.5, although here, 
the supplemental context is not an alternative to making the text 
easier to read: it's "both ... and ..." instead of "either ... or ..."


6. Avoid animated graphics. They can be visually distracting.

CS: See SC 2.2.2 and 2.2.3.


7. Where possible convert photos to thumbnails to minimize download 
time and to reduce to need to scroll through long pages.

CS: This looks like a technique for the recently proposed SC 1.4.8.


8. Minimum font size 14. Avoid use of bold font as it decreases readability.
Font colour: where possible use black/dark blue font on white or pale 
coloured backgrounds. Avoid yellow font as older readers view text as 
though through a yellow filter. Very bright colours tend to blur at 
the edges, creating "after images" and eye fatigue.

CS: The first part also maps well to the last bullet SC 1.4.8, 
although the SC has been softened by requiring only a mechanism 
instead of making the mechanism an alternative to using certain 
features by default.
Regarding font color: see the first bullet in SC 1.4.8.


9. Background colour: To differentiate between different pages within 
a site, vary the colour of the backgrounds for each page.

CS: At first glance, this could be seen as conflicting with WCAG 1.0 
checkpoint 14.3 (Create a style of presentation that is consistent 
across pages), but it can also be argued that the style is still 
consistent if background colour is the only style aspect that varies 
from page to page.
If a colour difference is used to convey information (i.e. "you are 
on a different page now"), this appears to fall under SC 1.4.1 (Use 
of Color), but the information conveyed by the colour difference is 
also visually evident without the colour difference (otherwise, it 
wouldn't be a different page).


10. Background Font style: keep to the simple "easy to read" fonts. 
This may seen boring, but it will be easier on the reader.

CS: As noted in a previous message, there seems to be no consensus 
regarding serif versus sans-serif fonts: 
<http://lists.w3.org/Archives/Public/w3c-wai-gl/2007JulSep/0173.html> 
(but more papers are available).



Formatting:


1. Use a one-column (or maximum 2 column with graphics) layout with 
generous margins on each side. A narrow reading column will lessen 
the load of reading long lines of text. White space also makes a page 
easier to read.

CS: Margins and line length are covered by the proposed SC 1.4.8 and 
its associated techniques.
I don't think we have any restrictions with regard to columns. 
Example 1 in technique G146 (Using liquid layout) uses three columns.


2. Use of frames can clearly delineate sections of text and graphics. 
(note: this recommendation may not suit users of computers with 
slower internet connections). Label frames clearly.

CS: See technique H70: Using frame elements to group blocks of 
repeated material (for SC 2.4.1 (Bypass Blocks)).


3. Use clear headings to break up page into more manageable content.

CS: See SC 2.4.9 Section Headings: Where content is organized into 
sections, the sections are indicated with headings, or - in the 
editor's draft: SC 2.4.10 Section Headings: Section headings are used 
to organize the content, combined with SC 2.4.6 (Labels Descriptive).


4. Avoid use of distracting banners, advertising images and logos. A 
person with literacy disability may find this clutter detracts from 
their ability to locate and use the browser's navigation toolbar.

CS: I don't think we have covered this anywhere (except for the 
subset of the issue covered by SC 2.2.2 and 2.2.3).



Navigation elements:

1. Organise pages predictably with the navigation bar in the same 
place on each page.

CS: See SC 3.2.3 (Consistent Navigation).


2. Maximum of 6 of links in navigation bar. Use of buttons in 
addition to links if necessary.

CS: This is not covered anywhere. The closes match to the first part 
is the future link "Limiting the number of links per page" under guideline 2.4.


[Numbers 3 and 4 don't exist.]
5. Use large buttons and links to facilitate mouse accuracy.

CS: This is not covered anywhere. Additional technique for SC 1.4.8?


6. Horizontal placement of navigation bar to leave maximum area for 
text and white space across table.

CS: This is not covered anywhere. Additional advisory technique for 
SC 3.2.3 (Consistent Navigation)?


7. Provide navigation mechanisms to assist orientation e.g. within 
page instructions, directions to previous/next page (text and 
non-text equivalent).

CS: This maps to SC 2.4.5 (Multiple Ways) and SC 2.4.7 (Location) (SC 
2.4.8 in the editor's draft).


8. Use internal links on web pages to minimize scrolling through long 
pages of text. Keep it simple and provide instructions if necessary.

CS: This seems to fit under guideline 2.4 but we have no specific SC 
for this. The closest match to the first part is the future link 
"Providing mechanisms to navigate to different sections of the 
content of a Web page" under guideline 2.4.



Best regards,

Christophe



[1] The guidelines can be downloaded as PDF or MS Word from 
<http://www.shrs.uq.edu.au/cdaru/aphasiagroups/Download_Guidelines.html>.

-- 
Christophe Strobbe
K.U.Leuven - Dept. of Electrical Engineering - SCD
Research Group on Document Architectures
Kasteelpark Arenberg 10 bus 2442
B-3001 Leuven-Heverlee
BELGIUM
tel: +32 16 32 85 51
http://www.docarch.be/  


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Received on Wednesday, 31 October 2007 20:54:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:51 GMT