[projectaon] [Fwd: Project Aon - LW Book 1 Web Accessibility - Robert Wellock]
- From: Simon Osborne <outspaced@xxxxxxxxxxxx>
- To: Project Aon <projectaon@xxxxxxxxxxxxx>
- Date: Tue, 17 Mar 2009 17:09:08 +0000
Hi
I know this is a bad time to bring this up, but I'm forwarding a 'report' on accessibility in Book 1
which could have implications for the other books too. Should we decide to implement this
information in the transform scripts, we might be reducing the size of each HTML page as well as
improving accessibility. I'm no expert, though, so I'm passing it on to people who know more than I
do . . . sorry . . . :-\
--
Simon Osborne
Project Aon
-------- Original Message --------
Subject: Project Aon [projectaon] - LW Book 1 Web Accessibility - Robert
Wellock
Date: Tue, 17 Mar 2009 16:32:44 +0000
From: Robert Wellock
Sorry the the HUGE amount of text I could have reduced it by a factor
of 90% but I don't know who needs the information and their
skill-sets.
I've had a very brief look at 'Web Accessibility and Semantics' for
the Project Aon 'Flight from the Dark' book.
Be warned this message is too wordy but I am not sure of what you
currently know about 'web accessibility'.
<begin>
Overview Section:
I am only including Sections 1-350, i.e. files beginning sect*.htm and
excluding any book illustrations, etc. Since the illustrations are a
more complex matter, I'll ignore them at this stage; neither will I be
considering the CSS Accessibility.
At the moment I'll just cover any 'accessibility issues' relating to
(x)html markup that stands-out. At later stage I shall address;
Illustrations, CSS and the remaining files, and so on... Clearly it's
just a brief study of the things would 'smack you in the face' as soon
as you viewed the 350 sect*.htm pages - minus illustrations.
I am slightly-dyslexic myself, so it does give me an advantage at
detecting 'accessibility issues' nonetheless the main boundary is the
paperback itself. The parameters the paperback imposes; on the 'web
edition' regarding the fidelity and 'likenesses' to the original piece
of work, will evidentially restrict how far we can accommodate for
'web accessibly'.
Even though there are 'imposed limitations' we should be able to make
the 'web edition' more accessible and semantically richer. I covered
the waffle so we'll get down to business - don't get offended by any
'suggestions' they are meant to be constructive criticisms. I do
realise the Project has a heavy-workload and are constantly altering
the XML rendering backend.
Basic Accessibility Review:
There were several things that I detected relating to possible
'accessibly hurdles' for Book 1 (sect*.htm) the good news is most of
them are rectifiable. Let us take as a generic example; sect181.htm.
The two major 'accessibility barriers' concerned; aspects of the
'image map' and the 'hard-coded colours' for the hyperlinks.
Hyperlink Issues:
The hyperlinks were hardcoded as follows:
<body text="#003300" bgcolor="#ffffe6" background="bckgrnd.png"
link="#006633" alink="#006633" vlink="#006633">
Apart from the code bloat - remember bloat gets multiplied over 350
times - and duplication of the link colour #063 the link colours were
defined in the CSS anyway. It's relatively safe to assume the major
mainstream browser bases are; Internet Explorer 6.0+, Mozilla Firefox
1.5+, Opera 9.0+ and Safari 3.0, all capable of interpreting the CSS
of the background, text and links.
The reason it is an 'accessibly barrier' 'hard-coding' the colours and
text is; the user cannot easily alter/override them should they be
colour-blind or such and need a 'user style sheet'. Furthermore not
having a different visited colour can hinder memory recall of where
the visitor has been. Similar issues can occur with the text colour
contrast and background image (which are both "Presentational Layer"
aspects).
Since you already have a CSS file it stands to reason the solution
would be to use that alone, it has superior control and independence
reducing rendering time hence you should just have standalone: <body>
remove the 6 irrelevant HTML BODY attributes, e.g. text, bgcolor,
background and *link.
Image Map Issues:
Secondly, we have the 'image map' title.png; image maps in themselves
can be 'barriers' since they usually assume the browser can render the
image correctly and that the user has a steady-hand and cognition.
Continuing with sect181.htm the 'image map' has two 'hotspots' linking
to (http://www.projectaon.org/) and (title.htm) with no clear
indication where the images join or the image border is, for that
matter. The implications are quite clear; if the user is 'mousing',
they have to 'guess' where the 'image map' is, including the hotspots
and as to where they lead.
The solution; to help alleviate the problem is to make better use of
the 'alternative and supportive' text and possibly enhance the hover
and focus states.
Currently you have as follows:
<img usemap="#imagemap" align="middle" border="0" height="100"
width="550" src="title.png" alt="Flight from the Dark" />
<map id="imagemap" name="imagemap"><area target="_top" alt="Project
Aon" href="http://www.projectaon.org/"; coords="0,0,99,99" shape="rect"
/><area href="title.htm" shape="default" alt="Flight from the Dark"
/></map>
Although the map code is in a slightly peculiar place it functions and
has 'alterative text' however it lacks informative supplemental text.
Hence if the browser has images disabled you can see the text "Flight
from the Dark" (first occurrence) which gives you a vague clue however
it is lacking... The user needs to know how to efficiently
interact/navigate with the 'image map' thus the 'title' attributes are
also required.
The solution is to adjust the ALT attributes and add the TITLE attributes.
For example:
<img usemap="#imagemap" align="middle" border="0" height="100"
width="550" src="title.png" alt="Flight from the Dark"
title="Navigation for Flight from the Dark, Joe Dever and Gary Chalk "
/>
This won't be displayed but accounts for the 'image map' itself as a
single entity then you would add two title attributes to each hotspot
loosely on the lines as below:
<map id="imagemap" name="imagemap"><area target="_top" alt="Project
Aon" href="http://www.projectaon.org/"; coords="0,0,99,99" shape="rect"
title="Project Aon (website)"/><area href="title.htm" shape="default"
alt="Flight from the Dark" title="Book Title Page" /></map>
Therefore when you hover over the 'Phoenix' you will be informed you
will be taken to Project Aon itself. Whereas if you hover over the
'text area' of the 'image map' you'll know you are heading towards the
book's 'title page'. Obviously they were crude examples of 'dummy
text' but conceptual, and even if the user used 'keyboard only'
navigation they should have a better experience.
Although in practice the browsers may differ in their interpretations
(damn M$IE argh!) but theoretically 'Screen Readers and text only
browsers', etc. should work fine. To be bluntly honest there doesn't
seem to be a strong reason for there to be an 'image map' since the
whole image is just separated in two adjacent 'rectangle' blocks. It
would possibly be better to slice the image and have two images; the
'Phoenix' and 'Book Title'. Since in effect that is what there already
is, and separating the image would make it more accessible and
constant cross-browser wise.
Furthermore there was the occurrence of the following: <area
target="_top" ...> which potentially would spawn a 'new window'
instance when the 'Phoenix' was activated via its associated
'hotspot'.
I am sure you are aware of the issues of spawning 'new windows'
without the users' consent – hence why popup blockers are popular. The
main pitfalls to using the target="_top" attribute are navigational
both in 'browser history' navigation via 'back button' and possibly
confusing the user about where they are – top window focus. At a bare
minimum I'd add a title attribute suggesting the item 'opens in a new
window' or alternatively - better option - use unobtrusive JavaScript.
Spawning windows is a "Behaviour Layer" process whereas 'HTML'
describes the "Content Layer" thus it's a misuse/abuse of a HTML Frame
feature.
Really, you should considerer if you actually do need the page to
spawn new browser window in the first place?
Image Navigation Issues:
After getting those 'two huge bugbears' out of the way it gets vastly
simpler sorting the accessibility barriers for 'sect*.htm' -
disregarding any page Illustrations.
The 3 bottom navigation images entitled 'Table of Contents' coded as follows:
<table border="0" cellpadding="0" cellspacing="0"><tr><td><img alt=""
border="0" height="30" width="150" src="left.gif" /></td><td><a
href="toc.htm"><img alt="Table of Contents" border="0" height="30"
width="150" src="toc.gif" /></a></td><td><img alt="" border="0"
height="30" width="150" src="right.gif" /></td></tr></table>
It makes very little sense wrapping the 3 images in a table; it is not
a table of contents neither is it tabular data. It serves no purpose
and if a 'screen-reader' was being used it would 'say' something like;
"Table has one row; Cell One: image, Cell Two, text: Table of
Contents, Cell Three: image" which of course just makes things
laborious and of no real value.
There is no benefit of the table especially since it just being abused
for 'Presentational' purpose.
It would be far simpler - more semantic - and use less code to just
have the images themselves adjacent to each other. For example:
<img alt="" border="0" height="30" width="150" src="left.gif" /><a
href="toc.htm"><img alt="Table of Contents" border="0" height="30"
width="150" src="toc.gif" /></a><img alt="" border="0" height="30"
width="150" src="right.gif" />
Removing the bloat of:
<table border="0" cellpadding="0"
cellspacing="0"><tr><td></td><td></td><td></td></tr></table>
Personally I'd control the border, width and height via CSS thus
cutting the navigation (350 occurrences) roughly down to as follows:
<img alt="" src="left.gif" /><a href="toc.htm"><img alt="Table of
Contents" src="toc.gif" /></a><img alt="" src="right.gif" />
Although the 'accessibly barrier' was the complete misuse of the TABLE element.
Semantics Issues:
The image map, hyperlinks and the navigation were the big three
'accessibility barriers' but as shown the problems were easily solved
and reduced code bloat.
The majority of the other issues were mainly semantic in nature and of
lesser importance.
Natural Language Issues:
There were 3 occurrences of Giak Speak; Orgadak taag [...]...,
Ogot...Ogot! and Ogot! Ogot! [...] ... RANEG ROGAG [...] ...
Under normal circumstances you give them a LANG attribute; it probably
wouldn't harm giving the words a class.
Theoretically it would be something like: <span
xml:lang="x-giak">Orgadak taag</span> which is fine since the x-
prefix, i.e. primary sub-tag "x" indicates an experimental language
tag (private use allowed).
The written Giak: Orgadak shada [...] ... obviously is treated the
same with 'x-giak'.
Technically speaking the three spoken occurrences should use <em> over
<i>, as the 'phrase element' EM gives emphasis to its contents and the
3 occurrences are in 'raised-voice' and not 'italic'.
Inventory Items:
(Hmmm needs work I'll do that later).
For the: acknwldg.htm " 'I would be especially pleased if my granting
[...] Joe Dever" Unless I am mistaken that is a spoken/written quote
from Joe Dever himself, in which case it should me marked up as a
BLOCKQUOTE and text Joe Dever needn't be in STRONG emphasis but rather
font weight styled.
</end>
So yeah those were the 3 BIG barriers for Sect 1-350!
Thanks
Robert Wellock
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.0.237 / Virus Database: 270.11.17/2007 - Release Date: 03/17/09
10:18:00
Other related posts:
