E-mail List Archives
Thread: Identifying link targets
Number of posts in this thread: 19 (In chronological order)
From: Martin Godfrey
Date: Tue, Sep 21 2004 10:51AM
Subject: Identifying link targets
No previous message | Next message →
= EMAIL ADDRESS REMOVED = pointed out a problem with a website we'd developed (thanks
Mary):
The link "Read More" appears multiple times on a page. When a person with a
screen reader brings up the list of links, the links will be out of context,
and so the user can't tell where a "Read More" link will go. Instead of
"Read More" you can link the text within the sentence or phrase.
This is a tricky one that we come across on lots of sites that are driven
from a CMS.
In the example cited we have body copy followed by a 'Read more' link, thus:
The 11th Duke of Devonshire's memoir, 'Accidents of Fortune' is now on sale
Read more
Now, for the purposes of this discussion, let's say this site is CMS driven
and we're pulling story summaries from a database and linking to the full
stories.
Of course it IS possible to embed a link within the story summary, but in
practical terms this is relatively complex (and therefore expensive) to do.
It's also useful for users to be able to scan through a summary and click on
a following link. Hence 'Read more'.
We could include a story headline which would become the link eg.
Memoir hits the shelves (linked)
The 11th Duke of Devonshire's memoir, 'Accidents of Fortune' is now on sale
However, this is less nice in that the user's flow is disrupted; they need
to backtrack to find the link. And not all information types lend themselves
to this solution.
One solution that we have implemented, with the agreement of RNIB, is to
include a link description which uniquely identifies the link eg.
Explanation of the law regarding minimum hourly rates paid to workers
<a href="some url" title="Order a copy of 'A general guide to Driver
Licensing' - http://www.dvla.gov.uk/contact/local_offices.htm - Opens in a
new window" >A general guide to Driver Licensing
(I've simplified the code here)
This seems a good compromise but we're aware that it's not quite 100%
foolproof in that some screen reader users may have turned off link
descriptions.
I wondered if anyone had any real-life examples of how they'd addressed this
issue ?
Thanks in advance.
Martin
----------------------------------------------------------------
Something you might like:
http://www.nykris.com/ppod
----------------------------------------------------------------
Martin Godfrey
Project Manager
NYKRIS, 148 Curtain Road, Shoreditch, London UK, EC2A 3AT
T: +44 [0]20 7749 9349
D: +44 [0]20 7749 9334
F: +44 [0]20 7729 8188
E: = EMAIL ADDRESS REMOVED =
http://www.nykris.com
Digital passion that delivers
----------------------------------------------------------------
From: Chris Heilmann
Date: Tue, Sep 21 2004 11:01AM
Subject: Re: Identifying link targets
← Previous message | Next message →
>
> The link "Read More" appears multiple times on a page. When a person with
> a
> screen reader brings up the list of links, the links will be out of
> context,
> and so the user can't tell where a "Read More" link will go. Instead of
> "Read More" you can link the text within the sentence or phrase.
>
>
> This is a tricky one that we come across on lots of sites that are driven
> from a CMS.
>
> In the example cited we have body copy followed by a 'Read more' link,
> thus:
>
> The 11th Duke of Devonshire's memoir, 'Accidents of Fortune' is now on
> sale
> Read more
A possibiliy would be to add a short title
The 11th Duke of Devonshire's memoir, 'Accidents of Fortune' is now on
sale
Read more about 'Accidents of Fortune'
That way you have an own wording for every link. This could also happen in
a title, although that is hacky and I doubt all screen readers/text
browsers read out titles.
As to your example of linking titles - I found in usability tests that
people do click on linked titles more than on the read more links. Best
option would be to do both (which is doubling the links for screen readers
again, something to ponder).
An interesting read are the results of eyetrack III in this context:
http://www.poynterextra.org/eyetrack2004/main.htm
HTH
Chris
From: Austin, Darrel
Date: Tue, Sep 21 2004 11:16AM
Subject: Re: Identifying link targets
← Previous message | Next message →
Martin asked:
>
> The link "Read More" appears multiple times on a page. When a person
> with a screen reader brings up the list of links, the links will be
> out of context, and so the user can't tell where a "Read More" link
> will go. Instead of "Read More" you can link the text within the
> sentence or phrase.
This is the same issue I'm having that I mentioned in a previous post with
the PDF/Word links issue.
The ideal solution, IMHO, is to use TITLE attributes for the links to
uniquely define them. BUT, I'm not sure if screen readers, by default, read
TITLE attributes. If they don't, I suppose it's a rather futile solution.
> This seems a good compromise but we're aware that it's not quite 100%
> foolproof in that some screen reader users may have turned off link
> descriptions.
Ah, yes...exactly. So, this is a recommended solution by the RNIB?
Is it fair to assume that those using a screen reader that encounter the
'duplicate links with the same name' issue would likely turn on the reading
of the TITLE attributes? (I guess I have exactly the same question as
Martin...apologies for being the echo in here ;o)
Lists38 suggested:
> A possibiliy would be to add a short title
> The 11th Duke of Devonshire's memoir, 'Accidents of Fortune' is now on
> sale
> Read more about 'Accidents of Fortune'
This is good, but causes issues with how to actually implement it with a
CMS. How would you your CMS to intelligently trim a long title? In my case,
where I need to list a document, and then provide a link to two different
file formats of the document, repeating the name of the document would get
incredibly verbose.
This is one of those cases where I feel Assistive Technology accessibility
can interfere with non AT usability...as much as I hate to admit it.
I did suggest using a semantic table in my last post, but didn't get much
feedback on whether it is a valid option. Something like this:
-------------------------------------------------------
TH(title) Memoir hits the shelves
-------------------------------------------------------
TD (teaser) The 11th Duke of Devonshire's memoir,
'Accidents of Fortune' is now on sale
-------------------------------------------------------
TD (link) Read More
-------------------------------------------------------
Would this accomodate a screen reader (reading the Read More link but also
the TH for the column)? Granted, for one article, this seems to be markup
overkill, but it is semantic, so perhaps a valid option.
-Darrel
From: Hall, Kevin (K.M.)
Date: Tue, Sep 21 2004 11:16AM
Subject: Re: Identifying link targets
← Previous message | Next message →
I recently moved from the Read More to using the linked titles on one of the sites I maintain. However, I'd also consider using the story title in the link text, saying 'continue reading Story Title' after the story excerpt. That way you don't have to worry about whether a screen reader reads the link title or not.
-Kevin Hall
-----Original Message-----
From: martin [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Tuesday, September 21, 2004 12:53 PM
To: "WebAIM Discussion List"
Subject: [WebAIM] Identifying link targets
= EMAIL ADDRESS REMOVED = pointed out a problem with a website we'd developed (thanks
Mary):
The link "Read More" appears multiple times on a page. When a person with a
screen reader brings up the list of links, the links will be out of context,
and so the user can't tell where a "Read More" link will go. Instead of
"Read More" you can link the text within the sentence or phrase.
This is a tricky one that we come across on lots of sites that are driven
from a CMS.
In the example cited we have body copy followed by a 'Read more' link, thus:
The 11th Duke of Devonshire's memoir, 'Accidents of Fortune' is now on sale
Read more
Now, for the purposes of this discussion, let's say this site is CMS driven
and we're pulling story summaries from a database and linking to the full
stories.
Of course it IS possible to embed a link within the story summary, but in
practical terms this is relatively complex (and therefore expensive) to do.
It's also useful for users to be able to scan through a summary and click on
a following link. Hence 'Read more'.
We could include a story headline which would become the link eg.
Memoir hits the shelves (linked)
The 11th Duke of Devonshire's memoir, 'Accidents of Fortune' is now on sale
However, this is less nice in that the user's flow is disrupted; they need
to backtrack to find the link. And not all information types lend themselves
to this solution.
One solution that we have implemented, with the agreement of RNIB, is to
include a link description which uniquely identifies the link eg.
Explanation of the law regarding minimum hourly rates paid to workers
<a href="some url" title="Order a copy of 'A general guide to Driver
Licensing' - http://www.dvla.gov.uk/contact/local_offices.htm - Opens in a
new window" >A general guide to Driver Licensing
(I've simplified the code here)
This seems a good compromise but we're aware that it's not quite 100%
foolproof in that some screen reader users may have turned off link
descriptions.
I wondered if anyone had any real-life examples of how they'd addressed this
issue ?
Thanks in advance.
Martin
----------------------------------------------------------------
Something you might like:
http://www.nykris.com/ppod
----------------------------------------------------------------
Martin Godfrey
Project Manager
NYKRIS, 148 Curtain Road, Shoreditch, London UK, EC2A 3AT
T: +44 [0]20 7749 9349
D: +44 [0]20 7749 9334
F: +44 [0]20 7729 8188
E: = EMAIL ADDRESS REMOVED =
http://www.nykris.com
Digital passion that delivers
----------------------------------------------------------------
----
To subscribe or unsubscribe, visit http://www.webaim.org/discussion/
From: julian.rickards@ndm.gov.on.ca
Date: Tue, Sep 21 2004 11:22AM
Subject: Re: Identifying link targets
← Previous message | Next message →
What about making the whole pr
From: Marissa Polsky
Date: Tue, Sep 21 2004 11:30AM
Subject: Re: Identifying link targets
← Previous message | Next message →
Following the same idea, if the client has some flexibility in using the
CMS, they can add another variable, and call it something like
"keyword." Then, if you don't want to necessarily repeat the story title
again in the link, you can have something like:
Scientists discover new miracle cure (title)
short text blah blah blah blah blah
Link: Read more about the miracle cure (and "the miracle cure" could be
the keyword).
Just a thought.
Marissa Polsky Goldsmith
-------------------------------------------------------------------------
Web Applications Developer
American Councils for International Education:
ACTR/ACCELS
http://www.russnet.org
http://www.americancouncils.org
(202) 833-7522
>>> = EMAIL ADDRESS REMOVED = 9/21/2004 1:07:00 PM >>>
I recently moved from the Read More to using the linked titles on one
of the sites I maintain. However, I'd also consider using the story
title in the link text, saying 'continue reading Story Title' after the
story excerpt. That way you don't have to worry about whether a screen
reader reads the link title or not.
-Kevin Hall
-----Original Message-----
From: martin [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Tuesday, September 21, 2004 12:53 PM
To: "WebAIM Discussion List"
Subject: [WebAIM] Identifying link targets
= EMAIL ADDRESS REMOVED = pointed out a problem with a website we'd developed
(thanks
Mary):
The link "Read More" appears multiple times on a page. When a person
with a
screen reader brings up the list of links, the links will be out of
context,
and so the user can't tell where a "Read More" link will go. Instead
of
"Read More" you can link the text within the sentence or phrase.
This is a tricky one that we come across on lots of sites that are
driven
from a CMS.
In the example cited we have body copy followed by a 'Read more' link,
thus:
The 11th Duke of Devonshire's memoir, 'Accidents of Fortune' is now on
sale
Read more
Now, for the purposes of this discussion, let's say this site is CMS
driven
and we're pulling story summaries from a database and linking to the
full
stories.
Of course it IS possible to embed a link within the story summary, but
in
practical terms this is relatively complex (and therefore expensive) to
do.
It's also useful for users to be able to scan through a summary and
click on
a following link. Hence 'Read more'.
We could include a story headline which would become the link eg.
Memoir hits the shelves (linked)
The 11th Duke of Devonshire's memoir, 'Accidents of Fortune' is now on
sale
However, this is less nice in that the user's flow is disrupted; they
need
to backtrack to find the link. And not all information types lend
themselves
to this solution.
One solution that we have implemented, with the agreement of RNIB, is
to
include a link description which uniquely identifies the link eg.
Explanation of the law regarding minimum hourly rates paid to
workers
<a href="some url" title="Order a copy of 'A general guide to Driver
Licensing' - http://www.dvla.gov.uk/contact/local_offices.htm - Opens
in a
new window" >A general guide to Driver Licensing
(I've simplified the code here)
This seems a good compromise but we're aware that it's not quite 100%
foolproof in that some screen reader users may have turned off link
descriptions.
I wondered if anyone had any real-life examples of how they'd addressed
this
issue ?
Thanks in advance.
Martin
----------------------------------------------------------------
Something you might like:
http://www.nykris.com/ppod
----------------------------------------------------------------
Martin Godfrey
Project Manager
NYKRIS, 148 Curtain Road, Shoreditch, London UK, EC2A 3AT
T: +44 [0]20 7749 9349
D: +44 [0]20 7749 9334
F: +44 [0]20 7729 8188
E: = EMAIL ADDRESS REMOVED =
http://www.nykris.com
Digital passion that delivers
----------------------------------------------------------------
----
To subscribe or unsubscribe, visit http://www.webaim.org/discussion/
----
To subscribe or unsubscribe, visit http://www.webaim.org/discussion/
From: Jukka K. Korpela
Date: Tue, Sep 21 2004 12:49PM
Subject: Re: Identifying link targets
← Previous message | Next message →
On Tue, 21 Sep 2004, darrel.austin wrote:
> The ideal solution, IMHO, is to use TITLE attributes for the links to
> uniquely define them.
No, the TITLE attribute should be regarded only as an optional hint,
since this is how it has effectively been defined and implemented.
The correct solution is to different link texts for links pointing to
different resources, as required even by accessibility guidelines.
> BUT, I'm not sure if screen readers, by default, read
> TITLE attributes.
They may, or they may not. If they do, consider it as a flaw.
The _adequate_ implementation is to make the TITLE attribute's value
available upon the user's request (as most graphic browsers do these
days).
> -------------------------------------------------------
> TH(title) Memoir hits the shelves
> -------------------------------------------------------
> TD (teaser) The 11th Duke of Devonshire's memoir,
> 'Accidents of Fortune' is now on sale
> -------------------------------------------------------
> TD (link) Read More
> -------------------------------------------------------
One possibility is to make the title a link. It works fairly well in most
circumstances, though with some inconvenience to users of speech browsers,
who need to go back a bit. Another option is to use
TD More info: (link) Memoir hits the shelves (end of link text)
It duplicates the title text, but that's tolerable.
And this approach gives the _option_ of making the title of the
presentation (in the TH) different from the title of the work advertized.
It could be something that "sells" the work better, in a particular
context, than its own title. Naturally, this would call for human work
(aka. "manual work"), but so does good advertizing in general.
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
From: Austin, Darrel
Date: Tue, Sep 21 2004 1:11PM
Subject: Re: Identifying link targets
← Previous message | Next message →
> No, the TITLE attribute should be regarded only as an optional hint,
> since this is how it has effectively been defined and implemented.
> The correct solution is to different link texts for links pointing to
> different resources, as required even by accessibility guidelines.
Fair enough, but I do think this is one of those areas where AT
accessibility clashes with non AT usability. Going back to the PDF vs. DOC
issue, my page would end up looking like this:
PDF: Petition for Appointment of Guardian of the Person/Conservator of the
Estate
DOC: Petition for Appointment of Guardian of the Person/Conservator of the
Estate
PDF: Notice of Hearing and Notice of Rights
DOC: Notice of Hearing and Notice of Rights
PDF: Physician's Statement in Support of Guardianship/Conservatorship (and
Re: Respondent's Inability to Attend Hearing)
DOC: Physician's Statement in Support of Guardianship/Conservatorship (and
Re: Respondent's Inability to Attend Hearing)
etc...
for a visual browser, this just makes all of my pages twice the size in
length and much harder to scan through. For a screen reader, it's easier to
distinguish between links, but there's still twice the number of links to
read through.
So, still thinking about a solution to this one... ;o)
-Darrel
From: Jukka K. Korpela
Date: Tue, Sep 21 2004 2:09PM
Subject: Re: Identifying link targets
← Previous message | Next message →
On Tue, 21 Sep 2004, darrel.austin wrote:
> > No, the TITLE attribute should be regarded only as an optional hint,
> > since this is how it has effectively been defined and implemented.
> > The correct solution is to different link texts for links pointing to
> > different resources, as required even by accessibility guidelines.
>
> Fair enough, but I do think this is one of those areas where AT
> accessibility clashes with non AT usability.
Sorry, "AT" is inaccessible to me... too many meanings for the
abbreviation. I guess however that you mean "assistive technologies". But
I wasn't discussing that, actually; I referred to both "usual" and
"unusual" user agents.
> Going back to the PDF vs. DOC
> issue, my page would end up looking like this:
>
> PDF: Petition for Appointment of Guardian of the Person/Conservator of the
> Estate
> DOC: Petition for Appointment of Guardian of the Person/Conservator of the
> Estate
Maybe, though it would be more logical to put "PDF" and "DOC" _after_ the
title proper. After all, it's a matter of data format, not content.
And when you offer something in DOC and PDF format only, you are already
in the inaccessible side. (Today I had to boot my computer twice due to
my being to fast in following links to PDF documents. And I'm a relatively
non-disabled user using a vanilla Windows system with vanilla additional
software.)
But if the options are not putting something onto the Web at all and
putting it in PDF and DOC format, I think we would vote for the latter.
Especially since for _some_ material, there's no feasible option of using
an accessible data format. (Mostly PDF-only, or DOC-only, or
PDF-and-DOC-only publishing is just a symptom of not understanding the
basics of usability and accessibility. I'm especially thinking about the
governmental organizations that keep publishing papers that nominally
preach accessibility to others and that are only available in PDF.)
Anyway, you are already in a less than optimal situation. Nobody can
reasonably expect the result to be perfect in all ways. But making the
linked resources name (title) the link text you gain quite a lot, even in
usability. Consider the "normal" user who moves the mouse over a link and
sees the link text change (color change, removal of underline, or
whatever). This is very useful feedback for checking, without much
noticing, that you hit the right link. Compare this with using "PDF" or
"DOC" as link text, for lots of links.
But there's yet another approach:
- put links to the PDF versions on one page and links to the DOC
versions on another; naturally you then use just the names as links,
and you have some general note on the format at the start
- naturally link the two documents to each other
- and the relative main page could contain links to the two pages,
or it could _be_ one of them if you wish to make one format or
another the preferred, or default, data format
- and that page could contain whatever general explanation you like
about the two formats and their relative merits, and information
to users who cannot use either of them (like "call us at - -").
This may result in a need for an extra click or equivalent to get to the
page with the right format, but it makes things simpler and cleaner.
Quite probably, each user, in each browsing situation, wants to select the
data format first, instead of downloading one document as PDF, another as
DOC (which is possible in my scenario, too, just a bit clumsy).
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
From: Glenda
Date: Tue, Sep 21 2004 2:22PM
Subject: Re: Identifying link targets
← Previous message | Next message →
Jumping in here without having read the whole thread, so I may be sticking
my foot in my mouth. Oh well, will save making lunch.
Why not something like:
Petition for Appointment of Guardian of the Person/Conservator of the
Estate (PDF</a}, <a href="..."
TITLE="abbreviated title - Word">DOC)
Notice of Hearing and Notice of Rights (.......)
blah blah blah
Personally I would add a html or rtf format too.
Cheers,
Glenda
-----Original Message-----
From: darrel.austin [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Tuesday, September 21, 2004 12:07 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Identifying link targets
> No, the TITLE attribute should be regarded only as an optional hint,
> since this is how it has effectively been defined and implemented.
> The correct solution is to different link texts for links pointing to
> different resources, as required even by accessibility guidelines.
Fair enough, but I do think this is one of those areas where AT
accessibility clashes with non AT usability. Going back to the PDF vs. DOC
issue, my page would end up looking like this:
PDF: Petition for Appointment of Guardian of the Person/Conservator of the
Estate
DOC: Petition for Appointment of Guardian of the Person/Conservator of the
Estate
PDF: Notice of Hearing and Notice of Rights
DOC: Notice of Hearing and Notice of Rights
PDF: Physician's Statement in Support of Guardianship/Conservatorship (and
Re: Respondent's Inability to Attend Hearing)
DOC: Physician's Statement in Support of Guardianship/Conservatorship (and
Re: Respondent's Inability to Attend Hearing)
etc...
for a visual browser, this just makes all of my pages twice the size in
length and much harder to scan through. For a screen reader, it's easier to
distinguish between links, but there's still twice the number of links to
read through.
So, still thinking about a solution to this one... ;o)
-Darrel
----
To subscribe or unsubscribe, visit http://www.webaim.org/discussion/
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.766 / Virus Database: 513 - Release Date: 9/17/04
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.766 / Virus Database: 513 - Release Date: 9/17/04
From: julian.rickards@ndm.gov.on.ca
Date: Tue, Sep 21 2004 2:51PM
Subject: Re: Identifying link targets
← Previous message | Next message →
Jukka wrote:
"I'm especially thinking about the governmental organizations that keep
publishing papers that nominally preach accessibility to others and that are
only available in PDF.)"
If you were discretely pointing at me, I raise my hand in acknowledgement.
We produce Publication Release notices and post them on our web site for the
purpose of alerting clients that new scientific studies are available
(reports, maps and digital data). However, Publication Services Section,
under my guidance, is working on an accessible HTML format instead with PDF
as a secondary format.
-----------------------------------------------
Julian Rickards
A/Digital Publications Distribution Coordinator
Publication Services Section,
Ministry of Northern Development and Mines,
Vox: 705-670-5608 / Fax: 705-670-5960
From: Glenda
Date: Tue, Sep 21 2004 3:04PM
Subject: Re: Identifying link targets
← Previous message | Next message →
Julian,
Or maybe he was referring to the BC government too! The report I prepared
for theem, with the Web accessibility audit, is only available as a pdf.
Aye aye aye. Will people ever get the concept of Web accessibility???
Cheers,
Glenda
-----Original Message-----
From: julian.rickards [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Tuesday, September 21, 2004 1:26 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Identifying link targets
Jukka wrote:
"I'm especially thinking about the governmental organizations that keep
publishing papers that nominally preach accessibility to others and that are
only available in PDF.)"
If you were discretely pointing at me, I raise my hand in acknowledgement.
We produce Publication Release notices and post them on our web site for the
purpose of alerting clients that new scientific studies are available
(reports, maps and digital data). However, Publication Services Section,
under my guidance, is working on an accessible HTML format instead with PDF
as a secondary format.
-----------------------------------------------
Julian Rickards
A/Digital Publications Distribution Coordinator
Publication Services Section,
Ministry of Northern Development and Mines,
Vox: 705-670-5608 / Fax: 705-670-5960
----
To subscribe or unsubscribe, visit http://www.webaim.org/discussion/
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.766 / Virus Database: 513 - Release Date: 9/17/04
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.766 / Virus Database: 513 - Release Date: 9/17/04
From: Kynn Bartlett
Date: Wed, Sep 22 2004 3:46AM
Subject: Re: Identifying link targets
← Previous message | Next message →
On Sep 21, 2004, at 9:53 AM, martin wrote:
> Explanation of the law regarding minimum hourly rates paid to
> workers
> <a href="some url" title="Order a copy of 'A general guide to Driver
> Licensing' - http://www.dvla.gov.uk/contact/local_offices.htm - Opens
> in a
> new window" >A general guide to Driver Licensing
>
> (I've simplified the code here)
>
> This seems a good compromise but we're aware that it's not quite 100%
> foolproof in that some screen reader users may have turned off link
> descriptions.
Then that's their choice. And they don't get the link descriptions.
Really, you don't have to compensate when people have access to
accessibility-
related information and don't choose to read/hear it.
The above method described is okay. It would also be okay if you wrote
"Read more" with a title on it.
I also maintain that if you just have "Read more", with NOTHING else,
you're not violating some cardinal sin.
Web pages are NOT meant to be read as a list of links. They are
structured
documents, and treating them as if they are not and structure does not
matter is as wrong as if you took all the elements and read them
in order. In fact, doing that makes more sense than reading tags.
This kind of thinking is dangerous to accessibility because it leads to
a devaluation of the structured aspects of HTML marked up text.
--Kynn
> --
Kynn Bartlett http://kynn.com
Chief Technologist, Idyll Mountain http://idyllmtn.com
Author, CSS in 24 Hours http://cssin24hours.com
Columnist, _The Californian_ http://kynn.com/column
AIM: NextOfKynn | Cell: (951) 202-9872 | Office: (951) 245-4020
From: Jukka K. Korpela
Date: Wed, Sep 22 2004 5:57AM
Subject: Re: Identifying link targets
← Previous message | Next message →
On Wed, 22 Sep 2004, kynn wrote:
> > This seems a good compromise but we're aware that it's not quite 100%
> > foolproof in that some screen reader users may have turned off link
> > descriptions.
>
> Then that's their choice. And they don't get the link descriptions.
Maybe they don't have a choice. We know for sure that authors have a
choice
> I also maintain that if you just have "Read more", with NOTHING else,
> you're not violating some cardinal sin.
For a definition of cardinal, ordinal, or some other sin, consult your
local &priest;.
Regarding accessibility, making link texts the same when they point to the
same resource reduces accessibility. It also violates a specific
requirement, WCAG 1.0 clause 13.1,
http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-meaningful-links
which is explicitly clarified at
http://www.w3.org/TR/WCAG10-HTML-TECHS/#link-text
as follows:
"If more than one link on a page shares the same link text, all those
links should point to the same resource. Such consistency will help page
design as well as accessibility."
If you read further, you see:
"If two or more links refer to different targets but share the same link
text, distinguish the links by specifying a different value for the
"title" attribute of each A element."
which is an unfortunate addition, but might be read bone fide as saying
that _if_ you have violated the accessibility principles, _then_ you
should at least reduce the damage that way.
> Web pages are NOT meant to be read as a list of links.
That's just your prejudice, and accessibility guidelines explicitly take
the view that pages _may_ be used that way and _are_ used that way.
A list of links is just one form of this; people may also tab through
links, or use a speech browser in "links reading mode".
> They are structured documents,
Yet another prejudice. Structured is not identical with sequentiality. On
the contrary, it's _minimally_ more that mere sequentiality, i.e. a
document that may only be consumed sequentially.
The markup is part of the structure, allowing, for example, the
extraction of links, just as heading markup allows a browser to construct
a table of content from them, or as markup (if it were used
properly) would allow the browser to give the use quick access to terms in
their definitions, etc.
> and treating them as if they are not and structure does not
> matter is as wrong as if you took all the elements and read them
> in order. In fact, doing that makes more sense than reading tags.
You are not consistent with yourself here. Anyway, reading just the
emphasized words is surely one way of looking at a document, especially in
visual browsing. People do that all the time.
> This kind of thinking is dangerous to accessibility because it leads to
> a devaluation of the structured aspects of HTML marked up text.
On the contrary, structural approach means that an HTML document can be
processed and "consumed" in a multitude of ways, instead of mere
sequentiality (which is, of course, an important mode too).
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
From: Jukka K. Korpela
Date: Wed, Sep 22 2004 6:07AM
Subject: Re: Identifying link targets
← Previous message | Next message →
On Wed, 22 Sep 2004, jkorpela wrote:
> Regarding accessibility, making link texts the same when they point to the
> same resource reduces accessibility.
.... when they point to _different resources_ ..., of course.
Sorry for my confusion; it's one of my bad habits to write the exact
opposite of the intended meaning, at times. (Whether link texts should be
the same when a page contains several links to the same resource is
a different issue, and a tricky one.)
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
From: Austin, Darrel
Date: Wed, Sep 22 2004 9:06AM
Subject: Re: Identifying link targets
← Previous message | Next message →
> Maybe, though it would be more logical to put "PDF" and "DOC" _after_
> the title proper. After all, it's a matter of data format, not
> content.
Some of these forms have extremely long titles. I thought it'd be odd to
have to sit through the title repeatedly just to find how which file format
it is.
> And when you offer something in DOC and PDF format only, you are
> already in the inaccessible side.
This is out of my hands. I agree with you, but this isn't a part of this
discussion for now, unfortunately.
> Anyway, you are already in a less than optimal situation. Nobody can
> reasonably expect the result to be perfect in all ways. But making the
> linked resources name (title) the link text you gain quite a lot,
> even in usability. Consider the "normal" user who moves the mouse
> over a link and sees the link text change (color change, removal of
> underline, or whatever). This is very useful feedback for checking,
> without much noticing, that you hit the right link. Compare this with
> using "PDF" or "DOC" as link text, for lots of links.
Well, I disagree on this one. For a sighted person, a table would make a lot
of sense:
form title DOC PDF
With some visual cues (row shading, etc.) It'd be very easy to scan down the
list of titles, then over to the appropriate file format.
Combining the file format WITH the title causes two usability problems: it
duplicates each entry, and removes the file format from an easily-scannable
columnar layout.
> But there's yet another approach:
> - put links to the PDF versions on one page and links to the DOC
> versions on another; naturally you then use just the names as links,
> and you have some general note on the format at the start
I was actually thinking about this too, and I do think this is another good
option. Pros: one title per item, you know what the file format it. Cons: if
you need both (some do) it's a bit more clicking. If you scan down a long
list only to realize it's the wrong format, switching the other page and
scrolling down again can get a tad tedious.
> Quite probably, each user, in each browsing situation, wants
> to select the data format first, instead of downloading one document
> as PDF, another as DOC (which is possible in my scenario, too, just a
> bit clumsy).
Well...we'd actually have folks that need both, but that wouldn't be the
majority.
Thanks for the suggestion. Another option to consider!
-Darrel
From: Austin, Darrel
Date: Wed, Sep 22 2004 9:09AM
Subject: Re: Identifying link targets
← Previous message | Next message →
> Why not something like:
>
> Petition for Appointment of Guardian of the Person/Conservator of the
> Estate (PDF</a}, <a
> href="..." TITLE="abbreviated title - Word">DOC)
> Notice of Hearing and Notice of Rights (.......)
Well, during this discussion, we've determined that title attributes aren't
a safe bet, as the major screen readers do not read these by default.
-Darrel
From: Sandy Clark
Date: Wed, Sep 22 2004 9:41AM
Subject: Re: Identifying link targets
← Previous message | Next message →
I tend to err on the safe side and create off-left spans around information.
So a table that contained
===================================== | DOC | PDF | |
=====================================
would be coded (th's left off for examples sake)
Word Document version
for DOC
Adobe Acrobat version
for DOC
I'm not saying that the information in the span is the exact information to
give (other suggestions on this thread have been helpful in that regard),
however, for myself at least, this compromise allows my visual users to have
a nicely laid out visual screen, while still allowing screen readers to have
differentiated links
Sandy Clark
http://www.shayna.com
CF Pretty Accessible at http://www.shayna.com/blog
Now offering 4 days Hands on CSS training October 11-14th. Rockville, MD.
For more information go to:
http://www.teratech.com/training/oc_classes.cfm#css
-----Original Message-----
Well, during this discussion, we've determined that title attributes aren't
a safe bet, as the major screen readers do not read these by default.
-Darrel
----
To subscribe or unsubscribe, visit http://www.webaim.org/discussion/
From: Mary Martinson Grossnickle
Date: Wed, Sep 22 2004 2:13PM
Subject: Re: Identifying link targets
← Previous message | No next message
>I also maintain that if you just have "Read more", with NOTHING else,
>you're not violating some cardinal sin.
>
>Web pages are NOT meant to be read as a list of links.
True, but in virtually every usability test I've done with people using
screen readers, the way they use the web is to first tab through all the
links on the page. The other common strategy is if the page has a lot of
links (and everyone's definition of "a lot" obviously varies), the immediate
reaction is to bring up the links list. So for both strategies, tabbing
through the links and bringing up the links list, the web page *is* read as
a list of links. I like many of the suggestions posted to this list as an
alternative to simply saying "Read more."
Mary