WebAIM - Web Accessibility In Mind

E-mail List Archives

RE: Long URLs in HREFs

for

From: Jukka Korpela
Date: Oct 31, 2002 12:59AM

Rachel < <EMAIL REMOVED> > wrote:

> I'm evaluating a dynamically generated site that has
> really long cryptic-sounding URLs inside all the links
> on the pages. Example: A
> HREF="main.jsp?BT_CODE=ANNOUNCE&BLURB_GEN_NBR=104036&TT_CODE=D"

I hope it does not generate exactly such URLs. That one is syntactically
incorrect, since an ampersand character must be "escaped" in HTML by writing
it as &amp; when it is followed by a letter. For the most of it, violating
this principle will go unnoticed, but when it will not, the effects will be
destructive and confusing. There are related notes in the document "4
Reasons to Validate your HTML",
http://www.htmlhelp.com/tools/validator/reasons.html
And as new entities may be added to (X)HTML, or be supported by browsers as
"extensions", it's really a time bomb to use constructs that are
syntactically entities and not meant to be that.

> Is this an issue for screen readers? Will the screen
> readers read the long URLs out loud?

They may, in various situations. Moreover, users will often _see_ long URLs,
and this can be mildly confusing. Typically, when I have followed a link, my
browser shows the URL in the browser's Location box. If I wish to tell the
URL to a friend of mine, or to put a link to it onto my own page, I need to
play with the long URL (and "escape" ampersands, and maybe modify the URL
otherwise too). It's difficult to send a long URL in an E-mail, for example.

Thus, although URLs are in principle just technical addresses that should be
hidden from users in normal use of the Web, the reality is different. URLs
are used, and currently need to be used, also as "names" that people
communicate with each other, or communicate with software. So they should
generally be short and mnemonic.

However, long and complicated URLs don't violate any specific accessibility
rule, as far as I can see. It's more a matter of general usability. A
so-called dynamically generated site, which is often effectively as static
in content as everyone's and his grandma's personal site, typically consists
of some database system and Web server software that generates pages upon
request from the database(s), which are actually handled so that a "static"
system with more user-friendly URLs would do just as fine, or better. But
after the decision to use a data base has been made*), there's probably
little you can do about it. However, the server probably supports mechanisms
for defining alias URLs that look like simple static URLs and/or making some
part of site static with such URLs, bypassing the database system
*) As regards to choosing to use a data base system, I would like to refer
to the Dilbert cartoon strip which is regrettably not in a very accessible
format, as the last one at
http://www.cafeshops.com/cp/category.aspx?category=bosses&;storeid=dilbert&ty
pe=strip

> In this case, the title of the link (what the A HREF
> wraps around) is much more comprehensible than the URL
> target of the link.

I presume you mean the _text_ of the link, the content of the <a> element.
It's naturally very important to make it comprehensible, much more important
than the URL issue. The phrase "title of the link" could also be understood
as referring to the advisory title defined using the TITLE attribute in an
<a> element. It's optional, but potentially helpful; it should be regarded
as an alternative to a good link text but as augmenting it. Example:
<a href="http://www.webaim.org/" title"Web Accessibility in Mind - Web accessibility information and solutions">
WebAIM</a>
I guess link titles are currently useful mostly to people using graphic
browsers, which may show them as "tooltips".

--
Jukka Korpela, senior adviser
TIEKE Finnish Information Society Development Centre
http://www.tieke.fi/
Diffuse Business Guide to Web Accessibility and Design for All:
http://www.diffuse.org/accessibility.html


----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/