[projectaon] Re: [Fwd: Project Aon - LW Book 1 Web Accessibility - Robert Wellock]
- From: Jonathan Blake <blake.jon@xxxxxxxxx>
- To: projectaon@xxxxxxxxxxxxx
- Date: Thu, 26 Mar 2009 12:11:15 -0700
On Tue, Mar 17, 2009 at 10:09 AM, Simon Osborne <outspaced@xxxxxxxxxxxx> wrote:
Simon, please share my thanks and responses for this audit of our
accessibility with Robert.
> Hyperlink Issues:
>
> The hyperlinks were hardcoded as follows:
>
> <body text="#003300" bgcolor="#ffffe6" background="bckgrnd.png"
> link="#006633" alink="#006633" vlink="#006633">
This is an example - the first of several - where we see that this
edition used to be the only edition and therefore had to fail
gracefully in even the most primitive browsers. Now that we have at
least one separate, simpler edition, I think we can safely remove some
of those fallbacks from our flagship edition, this example included.
> 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 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:
I'm unclear how this title attribute helps.
> <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.
Sounds good.
> 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.
Sounds OK.
> 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'.
Well behaved web browsing sofware will not spawn a new window with
this target. They will open the link in the top level frame if this
page is being displayed in a frameset. This is necessary for the old
Statskeeper program (perhaps others?), and since it doesn't do any
real harm, we'll keep this as it is.
> Image Navigation Issues:
> 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.
Ah yes tables. :) This is another example of a fallback for legacy
browsers. We can do this, though I imagine that text only browsers
will need a space between the images to avoid run-on of the alt text.
> 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).
I vaguely thought we were already doing this in this edition, but if
not, we should with both an xml:lang and lang attribute.
http://www.w3.org/TR/xhtml1/#C_7
> 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.
Another fallback that can be modernized, in this case, we can use <b></b> tags.
--
Jon
~~~~~~
Manage your subscription at //www.freelists.org/list/projectaon
Other related posts:
