E-mail List Archives
Thread: Acronym/Abbreviation best practice
Number of posts in this thread: 19 (In chronological order)
From: Jared Smith
Date: Thu, Mar 12 2009 10:35AM
Subject: Acronym/Abbreviation best practice
No previous message | Next message →
I'm struggling a bit with how best to expand acronyms and
abbreviations. Any insight you can provide would be valuable.
Which of the following do you believe is the best approach:
1. Expand only the first occurrence of the acronym in text -
"Assistive Technology (A.T.)" or "A.T. (Assistive Technology)"
This approach provides the expansion visually for all users. But if a
screen reader user jumps to a later instance of the acronym, they do
not get the expansion.
2. Expand only the first occurrence of the acronym using <acronym>
only - <acronym title="Assistive Technology">A.T.</acronym>
This approach provides the expansion, but as with #1 - only does so on
the first instance only.
3. Both 1 and 2 for only the first instance - Assistive Technology
(<acronym title="Assistive Technology">A.T.</acronym>)
This one seems redundant to me. A screen reader with
acronyms/abbreviations set to read would hear "Assistive Technology
Assistive Technology".
4. Expand all instances of the acronym using <acronym title="Assistive
Technology">.
This would always provide the expansion, but this could become VERY
tiresome - especially for long expansions (e.g., XHTML) and would
essentially negate the purpose of using the acronym.
5. Fully expand the first instance using <acronym title="Assistive
Technology">A.T.</acronym> then simply us <acronym>A.T.</acronym> for
all other instances.
Screen readers do nothing with acronyms if there is not a title
attribute, so only the first instance provides the needed expansion.
#5 still has the same problem as #3 if you also expand the first
instance in text.
So, which do you think is best? Or do you recommend some combination
of the above?
Of note is that WCAG 2.0 SC 1.3.4 allows #1 OR #4, but does not really
provide for any other possibilities -
http://www.w3.org/WAI/WCAG20/quickref/#qr-meaning-located
I would think that #5 would be the best approach, but only if screen
readers fully expanded the acronym at the first instance it is
encountered (which may not necessarily be the first one in the code
that has the full expansion with the title attribute). But screen
readers don't currently behave this way, so what do we do?
Jared Smith
WebAIM
PS - Also of interest is the fact that <acronym> is not part of the
HTML 5 spec. <abbr> would be used for all things acronymish -
http://dev.w3.org/html5/spec/Overview.html#the-abbr-element Also note
the <dfn> element which is intended to be used with <abbr> -
http://dev.w3.org/html5/spec/Overview.html#the-dfn-element
From: Karlen Communications
Date: Thu, Mar 12 2009 10:50AM
Subject: Re: Acronym/Abbreviation best practice
← Previous message | Next message →
I think it depends on the document. I've worked on documents where every
second word was an acronym which makes understanding the content difficult
even for people without disabilities. In that case we ended up writing the
full words because it also added better understanding and comprehension to
the document. There were also some "one off" acronyms that I think the
author had created just because they could. :-)
I would favour a combination of both with a dependence on the complexity of
the document. I use a screen reader and sometimes do tend to forget what an
acronym stands for in unfamiliar subject areas.
Cheers, Karen
From: Daniel Tang (dtang)
Date: Thu, Mar 12 2009 11:15AM
Subject: Re: Acronym/Abbreviation best practice
← Previous message | Next message →
Jared:
Your are great in that seek ideas from the audiences.
I believe that combination of the two makes sense. If the article is
short, expand in first occurrence will suffice. But if it is a long
passage, it will be helpful to expand it again. But do not expand it in
every occurrence.
Daniel Tang
Accessibility Specialist CCIE # 3681
Cisco Systems
170 W. Tasman
San Jose, CA 95134
Phone: 408 526 7814
Email: = EMAIL ADDRESS REMOVED =
From: Simius Puer
Date: Thu, Mar 12 2009 11:30AM
Subject: Re: Acronym/Abbreviation best practice
← Previous message | Next message →
I've encountered this too on many an occasion as working with Government
clients these are all too common.
I like the direction of Daniels suggestion but the problem there would be in
a) identifying how often to repeat the expansion (e.g. the first instance
after each <h2 / h3>...there is a debate in itself though not an interesting
one) and b) the maintenance procedures for the website...e.g. is this
programatically determined and output by a CMS or is the page manually
edited? If the latter is the case then I suspect this would be
unmanageable, especially if there is more than one person editing the
website.
Either way I concur with your argument against option #1 but it is not only
assistive technology users that can skip down the page - anyone can do that
which makes the argument for option #4 all the stronger and the one I would
recommend. Universal design, not just accessibility.
A solution may lie in the next version of XHTML
http://www.w3.org/TR/xhtml2/mod-text.html#sec_9.1. However even when this
is released the browser support is likely to be lacking for a while,
especially from a certain browser.
Oh, one final thing on the selection of abbr or acronym...the <abbr> tag is
not supported in IE 6 or earlier versions. If your target audience is using
this then just be aware of this. I know many people are beginning to refuse
to support IE6 but sometimes you have little choice (and trust me this is a
debate I don't want to start).
From: John E. Brandt
Date: Thu, Mar 12 2009 1:00PM
Subject: Re: Acronym/Abbreviation best practice
← Previous message | Next message →
IMHO I'm not sure the issue of readers who "jump around" an article not
getting the benefit of the definition of the acronym is that big a deal.
When reading, I find myself often doing this in both print formats as well
as digital/online formats. I know from experience that I sometimes have to
go back up into the beginning of the article/story to find more information.
This is not limited to acronyms. I find, particularly in newspaper articles,
that I need to go back up into the article to find out information provided
earlier in the story like the complete name of the person being quoted later
in the story. So, expecting screen reader users to do this also should not
be that big a deal - no?
I guess the best technological solution would be to have a smart
browser/screen reader combo that could look up all words, phrases and
abbreviations, figure out the definition (within the context) and provide
that info to the user on request. MS-Word can do this now, no reason why it
could not be incorporated into a browser. I believe there are some plugins
for Firefox that also do this by making calls out to Wikipedia or Google.
My personal belief is that we should use option 1. I tend to only use the
<acronym> tag when the acronym is typically used but may be misunderstood in
context. I am thinking that using the term AJAX in an article about web
design would be understood my most, but not all readers, and therefore the
<acronym> tag should be used on the 1st occurrence.
On the other hand, the acronym RADAR is almost universally know (and rarely
ever used with capital letters). This would not get the <acronym> tag.
Lastly, I try to break large articles up into smaller "pages" and will
repeat the "expansion" at the beginning of each page when the acronym is
used. In cases of automatic paging...I punt.
~j
John E. Brandt
Web Design, Development, Consultation
Augusta, Maine USA
www.jebswebs.com
= EMAIL ADDRESS REMOVED =
207-622-7937
From: Travis Roth
Date: Thu, Mar 12 2009 3:15PM
Subject: Re: Acronym/Abbreviation best practice
← Previous message | Next message →
For me, a screen reader user:
"1. Expand only the first occurrence of the acronym in text - "Assistive
Technology (A.T.)" or "A.T. (Assistive Technology)"
This approach provides the expansion visually for all users. But if a screen
reader user jumps to a later instance of the acronym, they do not get the
expansion."
Is fine for me. This is what I learned to do in writing class...
I can then either learn the way the screen reader pronounces the acronym, or
if it really becomes problematic I can use the dictionary tool of the screen
reader (most have it) to change it to something more suitable.
From: Chris Hoffman
Date: Thu, Mar 12 2009 5:35PM
Subject: Re: Acronym/Abbreviation best practice
← Previous message | Next message →
How about:
<abbr title="three-letter acronym" id="tla-abbr">TLA</abbr> is itself
a <abbr aria-describedby="tla-abbr">TLA</abbr>.
Yeah, yeah, it makes me a little uncomfortable, too. But I sure do
love me some ARIA.
Chris
On Thu, Mar 12, 2009 at 12:33 PM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
> I'm struggling a bit with how best to expand acronyms and
> abbreviations. Any insight you can provide would be valuable.
>
> Which of the following do you believe is the best approach:
>
> 1. Expand only the first occurrence of the acronym in text -
> "Assistive Technology (A.T.)" or "A.T. (Assistive Technology)"
> This approach provides the expansion visually for all users. But if a
> screen reader user jumps to a later instance of the acronym, they do
> not get the expansion.
>
> 2. Expand only the first occurrence of the acronym using <acronym>
> only - <acronym title="Assistive Technology">A.T.</acronym>
> This approach provides the expansion, but as with #1 - only does so on
> the first instance only.
>
> 3. Both 1 and 2 for only the first instance - Assistive Technology
> (<acronym title="Assistive Technology">A.T.</acronym>)
> This one seems redundant to me. A screen reader with
> acronyms/abbreviations set to read would hear "Assistive Technology
> Assistive Technology".
>
> 4. Expand all instances of the acronym using <acronym title="Assistive
> Technology">.
> This would always provide the expansion, but this could become VERY
> tiresome - especially for long expansions (e.g., XHTML) and would
> essentially negate the purpose of using the acronym.
>
> 5. Fully expand the first instance using <acronym title="Assistive
> Technology">A.T.</acronym> then simply us <acronym>A.T.</acronym> for
> all other instances.
> Screen readers do nothing with acronyms if there is not a title
> attribute, so only the first instance provides the needed expansion.
> #5 still has the same problem as #3 if you also expand the first
> instance in text.
>
>
> So, which do you think is best? Or do you recommend some combination
> of the above?
>
> Of note is that WCAG 2.0 SC 1.3.4 allows #1 OR #4, but does not really
> provide for any other possibilities -
> http://www.w3.org/WAI/WCAG20/quickref/#qr-meaning-located
>
> I would think that #5 would be the best approach, but only if screen
> readers fully expanded the acronym at the first instance it is
> encountered (which may not necessarily be the first one in the code
> that has the full expansion with the title attribute). But screen
> readers don't currently behave this way, so what do we do?
>
> Jared Smith
> WebAIM
>
> PS - Also of interest is the fact that <acronym> is not part of the
> HTML 5 spec. <abbr> would be used for all things acronymish -
> http://dev.w3.org/html5/spec/Overview.html#the-abbr-element Also note
> the <dfn> element which is intended to be used with <abbr> -
> http://dev.w3.org/html5/spec/Overview.html#the-dfn-element
>
From: Randi
Date: Thu, Mar 12 2009 5:50PM
Subject: Re: Acronym/Abbreviation best practice
← Previous message | Next message →
I've been trying to wrap my mind around this. I'm guessing you're
discussing something the actual programing which would repeat
descriptions of acronyms at every occurance? If I'm correct, why does
it need to be different for screenreader users thatn for sighted
people? For example, at the beginning of an artical about SAAVI it
might say, SAAVI, the Southern Arizona Association of the Visually
Impaired, began, lah blah. Then for the rest of the article, it would
just say SAAVI. So you're asking whether it should repeat the whole
description? Why? If I read the acronym at the beginning of an
oarticle, I'll either remember it or I won't. I guess being a recent
screenreader user, I don't find it necessry. My main thing is
navigation. I can usually decipher acronyms and such from context,
just like when there's typos when I'm chatting. Like I don't know what
ajax is but I assume its something to do with programming. If I want
to know more, I google, or ask. So I guess I'm just trying to say that
I use the screenreader the same way I surfed when I could see. Like
was mentioned, I can just go back to the beginning of the article.
(I'm still leary of posting because I'm just an ordinary screenreader
user with no programming knowledge haha)
On 3/12/09, Chris Hoffman < = EMAIL ADDRESS REMOVED = > wrote:
> How about:
>
> <abbr title="three-letter acronym" id="tla-abbr">TLA</abbr> is itself
> a <abbr aria-describedby="tla-abbr">TLA</abbr>.
>
> Yeah, yeah, it makes me a little uncomfortable, too. But I sure do
> love me some ARIA.
>
> Chris
>
> On Thu, Mar 12, 2009 at 12:33 PM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>> I'm struggling a bit with how best to expand acronyms and
>> abbreviations. Any insight you can provide would be valuable.
>>
>> Which of the following do you believe is the best approach:
>>
>> 1. Expand only the first occurrence of the acronym in text -
>> "Assistive Technology (A.T.)" or "A.T. (Assistive Technology)"
>> This approach provides the expansion visually for all users. But if a
>> screen reader user jumps to a later instance of the acronym, they do
>> not get the expansion.
>>
>> 2. Expand only the first occurrence of the acronym using <acronym>
>> only - <acronym title="Assistive Technology">A.T.</acronym>
>> This approach provides the expansion, but as with #1 - only does so on
>> the first instance only.
>>
>> 3. Both 1 and 2 for only the first instance - Assistive Technology
>> (<acronym title="Assistive Technology">A.T.</acronym>)
>> This one seems redundant to me. A screen reader with
>> acronyms/abbreviations set to read would hear "Assistive Technology
>> Assistive Technology".
>>
>> 4. Expand all instances of the acronym using <acronym title="Assistive
>> Technology">.
>> This would always provide the expansion, but this could become VERY
>> tiresome - especially for long expansions (e.g., XHTML) and would
>> essentially negate the purpose of using the acronym.
>>
>> 5. Fully expand the first instance using <acronym title="Assistive
>> Technology">A.T.</acronym> then simply us <acronym>A.T.</acronym> for
>> all other instances.
>> Screen readers do nothing with acronyms if there is not a title
>> attribute, so only the first instance provides the needed expansion.
>> #5 still has the same problem as #3 if you also expand the first
>> instance in text.
>>
>>
>> So, which do you think is best? Or do you recommend some combination
>> of the above?
>>
>> Of note is that WCAG 2.0 SC 1.3.4 allows #1 OR #4, but does not really
>> provide for any other possibilities -
>> http://www.w3.org/WAI/WCAG20/quickref/#qr-meaning-located
>>
>> I would think that #5 would be the best approach, but only if screen
>> readers fully expanded the acronym at the first instance it is
>> encountered (which may not necessarily be the first one in the code
>> that has the full expansion with the title attribute). But screen
>> readers don't currently behave this way, so what do we do?
>>
>> Jared Smith
>> WebAIM
>>
>> PS - Also of interest is the fact that <acronym> is not part of the
>> HTML 5 spec. <abbr> would be used for all things acronymish -
>> http://dev.w3.org/html5/spec/Overview.html#the-abbr-element Also note
>> the <dfn> element which is intended to be used with <abbr> -
>> http://dev.w3.org/html5/spec/Overview.html#the-dfn-element
>>
From: Webb, KerryA
Date: Thu, Mar 12 2009 6:00PM
Subject: Re: Acronym/Abbreviation best practice
← Previous message | Next message →
>
> I've been trying to wrap my mind around this. I'm guessing you're
> discussing something the actual programing which would repeat
> descriptions of acronyms at every occurance? If I'm correct, why does
> it need to be different for screenreader users thatn for sighted
> people? For example, at the beginning of an artical about SAAVI it
> might say, SAAVI, the Southern Arizona Association of the Visually
> Impaired, began, lah blah. Then for the rest of the article, it would
> just say SAAVI. So you're asking whether it should repeat the whole
> description? Why? If I read the acronym at the beginning of an
> oarticle, I'll either remember it or I won't. I guess being a recent
> screenreader user, I don't find it necessry. My main thing is
> navigation. I can usually decipher acronyms and such from context,
> just like when there's typos when I'm chatting. Like I don't know what
> ajax is but I assume its something to do with programming. If I want
> to know more, I google, or ask. So I guess I'm just trying to say that
> I use the screenreader the same way I surfed when I could see. Like
> was mentioned, I can just go back to the beginning of the article.
>
As I understand it, a sighted reader will be able to scan through a page
and will be able to quickly see where an acronym is first explained. A
person using a screen reader might be quickly stepping through the links
and may not know what SAAVI is if that appears in a link.
Kerry
-----------------------------------------------------------------------
This email, and any attachments, may be confidential and also privileged. If you are not the intended recipient, please notify the sender and delete all copies of this transmission along with any attachments immediately. You should not copy or use it for any purpose, nor disclose its contents to any other person.
-----------------------------------------------------------------------
From: Randi
Date: Thu, Mar 12 2009 6:25PM
Subject: Re: Acronym/Abbreviation best practice
← Previous message | Next message →
Oh gotcha. I see what you mean. I guess I didn't think of that since I
always start at the top of articles, so I'd catch the acronym.. Thank
you for the explanation.
On 3/12/09, Webb, KerryA < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> I've been trying to wrap my mind around this. I'm guessing you're
>> discussing something the actual programing which would repeat
>> descriptions of acronyms at every occurance? If I'm correct, why does
>> it need to be different for screenreader users thatn for sighted
>> people? For example, at the beginning of an artical about SAAVI it
>> might say, SAAVI, the Southern Arizona Association of the Visually
>> Impaired, began, lah blah. Then for the rest of the article, it would
>> just say SAAVI. So you're asking whether it should repeat the whole
>> description? Why? If I read the acronym at the beginning of an
>> oarticle, I'll either remember it or I won't. I guess being a recent
>> screenreader user, I don't find it necessry. My main thing is
>> navigation. I can usually decipher acronyms and such from context,
>> just like when there's typos when I'm chatting. Like I don't know what
>> ajax is but I assume its something to do with programming. If I want
>> to know more, I google, or ask. So I guess I'm just trying to say that
>> I use the screenreader the same way I surfed when I could see. Like
>> was mentioned, I can just go back to the beginning of the article.
>>
>
> As I understand it, a sighted reader will be able to scan through a page
> and will be able to quickly see where an acronym is first explained. A
> person using a screen reader might be quickly stepping through the links
> and may not know what SAAVI is if that appears in a link.
>
> Kerry
>
> -----------------------------------------------------------------------
> This email, and any attachments, may be confidential and also privileged. If
> you are not the intended recipient, please notify the sender and delete all
> copies of this transmission along with any attachments immediately. You
> should not copy or use it for any purpose, nor disclose its contents to any
> other person.
> -----------------------------------------------------------------------
>
From: Dan Conley
Date: Fri, Mar 13 2009 8:35AM
Subject: Re: Acronym/Abbreviation best practice
← Previous message | Next message →
This is interesting... when I started coding I read the A List Apart
article about abbreviations (I think it was called An Abbreviation
Triple Play or something), which advocated not only expanding everything
but also linking to a glossary (since IE6 doesn't recognize the abbr
tag). We no longer link to a glossary for a few reasons (the high number
of links it created being one), but I still expand everything. Is there
a reason not to, besides 'it takes a lot of work?' (find/replace,
especially with regex, helps a lot in those circumstances)
Dan Conley
Information Specialist
Center for International Rehabilitation Research Information and
Exchange (CIRRIE)
University at Buffalo, Health Sciences Library B6
Phone: (716) 829-3900 x145
= EMAIL ADDRESS REMOVED =
http://cirrie.buffalo.edu
Randi wrote:
> Oh gotcha. I see what you mean. I guess I didn't think of that since I
> always start at the top of articles, so I'd catch the acronym.. Thank
> you for the explanation.
>
> On 3/12/09, Webb, KerryA < = EMAIL ADDRESS REMOVED = > wrote:
>>> I've been trying to wrap my mind around this. I'm guessing you're
>>> discussing something the actual programing which would repeat
>>> descriptions of acronyms at every occurance? If I'm correct, why does
>>> it need to be different for screenreader users thatn for sighted
>>> people? For example, at the beginning of an artical about SAAVI it
>>> might say, SAAVI, the Southern Arizona Association of the Visually
>>> Impaired, began, lah blah. Then for the rest of the article, it would
>>> just say SAAVI. So you're asking whether it should repeat the whole
>>> description? Why? If I read the acronym at the beginning of an
>>> oarticle, I'll either remember it or I won't. I guess being a recent
>>> screenreader user, I don't find it necessry. My main thing is
>>> navigation. I can usually decipher acronyms and such from context,
>>> just like when there's typos when I'm chatting. Like I don't know what
>>> ajax is but I assume its something to do with programming. If I want
>>> to know more, I google, or ask. So I guess I'm just trying to say that
>>> I use the screenreader the same way I surfed when I could see. Like
>>> was mentioned, I can just go back to the beginning of the article.
>>>
>> As I understand it, a sighted reader will be able to scan through a page
>> and will be able to quickly see where an acronym is first explained. A
>> person using a screen reader might be quickly stepping through the links
>> and may not know what SAAVI is if that appears in a link.
>>
>> Kerry
>>
>> -----------------------------------------------------------------------
>> This email, and any attachments, may be confidential and also privileged. If
>> you are not the intended recipient, please notify the sender and delete all
>> copies of this transmission along with any attachments immediately. You
>> should not copy or use it for any purpose, nor disclose its contents to any
>> other person.
>> -----------------------------------------------------------------------
>>
From: Jared Smith
Date: Fri, Mar 13 2009 9:05AM
Subject: Re: Acronym/Abbreviation best practice
← Previous message | Next message →
On Fri, Mar 13, 2009 at 8:35 AM, Dan Conley wrote:
> Is there a reason not to, besides 'it takes a lot of work?'
> (find/replace, especially with regex, helps a lot in those
> circumstances)
Consider the WebAIM site where we use a lot of acronyms. It would, for
example, be quite annoying to hear "Asynchronous Javascript and XML"
for every instance of "AJAX". Now if screen readers were smart enough
to only expand it in the first instance or on demand, then it would be
less burdensome. You could also argue that the styling (typically a
dotted underline) of all acronyms impacts readability of text. If the
acronym is always expanded, the user may not even learn the acronym at
all.
For the record, we're in the process of removing acronym from all
relatively well-known acronyms (HTML, CSS, etc.) on our site. This
might not be appropriate for other sites, but for our site and our
audience, I think it makes sense. Less well-known acronyms (W3C, WCAG,
etc.) will be expanded in text in their first instance and then not
marked up with acronym. Very unknown and less commonly used acronyms
(SMIL, SAMI, etc.) will be expanded in text in the first instance and
marked up with <acronym> in all instances (or at least significant
instances - such as immediately after new headings). In short, my
thinking right now is to pretty much get rid of <acronym> on the site
except for the occasional unknown acronyms/abbreviations.
And yes, this will make it so we are never WCAG 2.0 AAA compliant. Meh.
Jared Smith
WebAIM
From: Simius Puer
Date: Fri, Mar 13 2009 9:40AM
Subject: Re: Acronym/Abbreviation best practice
← Previous message | Next message →
None at all Dan. Not unless you have so many abbreviations that the
additional mark-up suddenly blows your document-weight out of the water
(which is frankly unlikely).
What seems to be being overlooked here is that the problem is not one of
just sighted users vs those using assistive technologies such as Jaws.
Other people who need these explainations include: those with disabilities
such as dyslexia, cognitive disabilities such as dementia, and other users
including children, the elderly, and foreign language learners. Not having
*every *tag marked up in some way affects these users.
I think the article you are referring to is "The Accessibility Hat Trick:
Getting Abbreviations Right" which can be read here:
http://www.alistapart.com/articles/hattrick/ and covers all the aspects that
have been covered in this debate so far. Most importantly *it deals with
the accessibility vs visual aesthetics debate* which seems to be the crunch
point that most people have an issue with. So, you can achieve both with a
little work - pls refer to the article.
Oh, and I totally forgot to mention in my last post that XHTML 2 also drops
the <acronym> tag in favor of the <abbr> one alone
[1<http://www.w3.org/TR/xhtml2/mod-text.html#sec_9.1.>]
so no more confusion there!
And before I forget...a big happy birthday to the WWW (or should that be
<abbr title"World Wide Web">WWW</abbr>), 20 today!
Have a great weekend everyone.
From: John E. Brandt
Date: Fri, Mar 13 2009 10:40AM
Subject: Re: Acronym/Abbreviation best practice
← Previous message | Next message →
>>
And before I forget...a big happy birthday to the WWW (or should that be
<abbr title"World Wide Web">WWW</abbr>), 20 today!
<<
Curious - how do you come up with this date?
I did a Wikipedia search and found a reference to a "proposal" written by
Tim Berners-Lee in March 1989. Do you have a source?
http://en.wikipedia.org/wiki/WWW#History
http://www.w3.org/History/1989/proposal.html
I'm always up for a party!
~j
PS: I'm also enjoying the discussion on the abbreviation/acronym thing -
keep it up.
John E. Brandt
Web Design, Development, Consultation
Augusta, Maine USA
www.jebswebs.com
= EMAIL ADDRESS REMOVED =
207-622-7937
From: Jens Brueckmann
Date: Fri, Mar 13 2009 10:55AM
Subject: Re: Acronym/Abbreviation best practice
← Previous message | Next message →
> And before I forget...a big happy birthday to the WWW (or should that be
> <abbr title"World Wide Web">WWW</abbr>), 20 today!
> <<
>
> Curious - how do you come up with this date?
>
> I did a Wikipedia search and found a reference to a "proposal" written by
> Tim Berners-Lee in March 1989. Do you have a source?
http://info.cern.ch/www20/
--
Jens Brueckmann
http://www.yalf.de
From: John E. Brandt
Date: Fri, Mar 13 2009 11:00AM
Subject: Re: Acronym/Abbreviation best practice
← Previous message | Next message →
Many thanks....also found this:
http://www.sciam.com/report.cfm?id=web-20-anniversary
Happy B-day
~j
John E. Brandt
Web Design, Development, Consultation
Augusta, Maine USA
www.jebswebs.com
= EMAIL ADDRESS REMOVED =
207-622-7937
From: Simius Puer
Date: Fri, Mar 13 2009 11:15AM
Subject: Re: Acronym/Abbreviation best practice
← Previous message | Next message →
hehe - sorry for taking everyone off-topic by my remark. Hope the
administrators don't mind, it is Friday after all.
John, I was indeed referring to the
http://www.w3.org/History/1989/proposal.html. Whilst this was not the WWW
itself, nor indeed the final proposal document that got approved, it is
recognised as the real birth of the Web and was indeed written 20 years ago
today (thanks for the link Jens).
*Andrew*
2009/3/13 John E. Brandt < = EMAIL ADDRESS REMOVED = >
> Many thanks....also found this:
> http://www.sciam.com/report.cfm?id=web-20-anniversary
>
> Happy B-day
>
> ~j
>
> John E. Brandt
> Web Design, Development, Consultation
> Augusta, Maine USA
> www.jebswebs.com
> = EMAIL ADDRESS REMOVED =
> 207-622-7937
>
>
>
From: Christophe Strobbe
Date: Thu, Mar 19 2009 9:45AM
Subject: Re: Acronym/Abbreviation best practice
← Previous message | Next message →
Hi Jared,
At 16:01 13/03/2009, Jared Smith wrote:
>On Fri, Mar 13, 2009 at 8:35 AM, Dan Conley wrote:
> > Is there a reason not to, besides 'it takes a lot of work?'
> > (find/replace, especially with regex, helps a lot in those
> > circumstances)
>
>Consider the WebAIM site where we use a lot of acronyms. It would, for
>example, be quite annoying to hear "Asynchronous Javascript and XML"
>for every instance of "AJAX". Now if screen readers were smart enough
>to only expand it in the first instance or on demand, then it would be
>less burdensome. You could also argue that the styling (typically a
>dotted underline) of all acronyms impacts readability of text. If the
>acronym is always expanded, the user may not even learn the acronym at
>all.
>
>For the record, we're in the process of removing acronym from all
>relatively well-known acronyms (HTML, CSS, etc.) on our site.
Could you explain why you are removing acronym markup for well-known acronyms?
The dotted underline can be addressed with CSS, so I assume the
reason is something else.
Best regards,
Christophe
>This
>might not be appropriate for other sites, but for our site and our
>audience, I think it makes sense. Less well-known acronyms (W3C, WCAG,
>etc.) will be expanded in text in their first instance and then not
>marked up with acronym. Very unknown and less commonly used acronyms
>(SMIL, SAMI, etc.) will be expanded in text in the first instance and
>marked up with <acronym> in all instances (or at least significant
>instances - such as immediately after new headings). In short, my
>thinking right now is to pretty much get rid of <acronym> on the site
>except for the occasional unknown acronyms/abbreviations.
>
>And yes, this will make it so we are never WCAG 2.0 AAA compliant. Meh.
>
>Jared Smith
>WebAIM
--
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/
---
Please don't invite me to LinkedIn, Facebook, Quechup or other
"social networks". You may have agreed to their "privacy policy", but
I haven't.
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
From: Jared Smith
Date: Thu, Mar 19 2009 11:35AM
Subject: Re: Acronym/Abbreviation best practice
← Previous message | No next message
On Thu, Mar 19, 2009 at 9:39 AM, Christophe Strobbe
< = EMAIL ADDRESS REMOVED = > wrote:
> Could you explain why you are removing acronym markup for well-known acronyms?
> The dotted underline can be addressed with CSS, so I assume the
> reason is something else.
It is because screen readers read the full expansion for all
instances. It's unfair and decreases accessibility for screen reader
users to hear "HyperText Markup Language" in place of HTML in all
instances, for example. I don't think anything is lost for screen
reader and for non-screen reader users if the acronym is removed in
these instances of well known acronyms.
Jared Smith
WebAIM