Plural abbreviations and acronyms
Home / Site Building & Testing / Plural abbreviations and acronyms
The blog entry you are referring to is about expanding abbreviations and acronyms when <abbr> and <acronym> are used, that is another kind of problem.
I am stating that these tags should not be used when an abbreviation or acronym has a contraction (like in plural form). In general it is considered best practice to never write in contractions on the net (because of accessibility) because some screenreaders will actually pronounce the apostrophy as "apostrophy".
The rule of thumb being:
"When in doubt always make things as clear as possible"
Share: 
| Pent55 wrote: |
| In general it is considered best practice to never write in contractions on the net (because of accessibility) because some screenreaders will actually pronounce the apostrophy as "apostrophy". |
Do you have any references for this? I've never heard of it.
If a screen reader voices don't as don apostrophe tee then it's the fault of the screen reader and its programmers.
I'm no expert on the history of language, but I would guess that contractions have been in use for hundreds of years. It's unrealistic to expect people to change how they write just to accommodate a piece of broken software.
Share:
| Quote: |
| It's unrealistic to expect people to change how they write just to accommodate a piece of broken software. |
Just as it is to expect people to accomodate for browsers that do not support webstandards?
Anyway, Most screenreaders will read "don't" correctly as they will all commonly used contractions. But that is not to say they will read ALL contractions correctly. Esp. those (as this is what this topic is about) abbreviations/acronyms in plural form. I use a screenreader myself. I am not blind but have bad eye's. and the screenreader is for me an extra aid which comes in most helpfull when I am tired.
I can tell you, first hand, my computer more often than not will "tell" me something different than it "shows" me.
I became a member of this forum because I was curious as to how sighted people view accessibility and because I am a webdesigner myself. I am happy that so many become aware of the need for this, but I find it disturbing to see how discussions about the correct use of <abbr> and <acronym> get so much attention (there are other examples, but I choose this topic as it seems to pop up a lot on many forums).
Even if we could come to a consensus on how to correctrly use these, do you really think it would improve accessibility?
I worked for a company that educated and tested people in the field of accessibility. It was surprising to see how normal sighted people with a normal intelectual capacity had to scroll back up in order to view the written out definition of an abbreviation when it popped up again later on in the text.
We learned from all our testing: accessibility is not about using webstandards to the letter and it is not about taking things for granted.
Neither people nor software are "perfect". So yes, you need to expect people to change how they write (and code!) to accommodate both software and other people.
Either that or accept the fact that you cannot make 100% accessible sites based on those limitations.
Share:
| Pent55 wrote: |
| Even if we could come to a consensus on how to correctrly use these, do you really think it would improve accessibility? |
| Pent55 wrote: |
| I worked for a company that educated and tested people in the field of accessibility. |
| Pent55 wrote: |
| So yes, you need to expect people to change how they write (and code!) to accommodate both software and other people. |
| Pent55 wrote: |
| Either that or accept the fact that you cannot make 100% accessible sites based on those limitations. |
(EDIT) Oh, here's a good one:
| Code: |
| <acronym title="Assistive Technology">AT</acronym>s |
| Code: |
| <acronym title="Assistive Technologies">ATs</acronym> |
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Last edited by Ben Millard on 04 Aug 2007 08:15 am; edited 1 time in total
Share:
| Quote: |
| how would you define what is "accessible" |
I'm taking a huge shortcut here, but:
accessible is when when the entire content (text, links, formfields, etc. etc.) can be "read" unambiguously and uncluttered by everyone.
A web site is usable when the user can find what he/she wants or needs (topics, navigation, etc.) without effort.
This means you can make accessible web sites that are not usable and usable web sites that are not accessible.
| Quote: |
| Well, you seem to think so |
I am sorry if you got that impression. I am not saying I know better, I am merely trying to say that discussions regarding how to implement certain web practices may not always lead to better accessibility practices. Never take anything for granted.
If you ask my personal opinion on this topic I would say that:
the best solution would be if visual user agents could display the title attribute before or after the actual element-content (if so instructed) and if aural user agents would disregard the element-content and only read out the title attribute. Or better yet, the other way around. Why not have the standard be: <abbr title="AT">Assistive Technology</abbr>.
The problem is that visual user agents don't (yet) support all web standards because with :before, :after and attr() this could be made possible. Unfortunatly we may only dream of aural user agents that may one day support stylesheets.
As I understand it, developers of screanreaders so not like stylesheets because it "takes away control from the user". They fear their users will be confronted with voice and pitch changes. And they are right. CSS should not include things like voice, pitch, etc. these are very important aspects that should not be fiddled with. But they shoudl include things like speak: normal and speak: none to be able to hide and unhide certain elements from different user-groups.
I have no idea if the majorty of blind people actually dislike the fact that "control is taken away from them", but if this is so, why does the worldwide consortium put so much resources into aural stylesheets?
Yes, aural user agents shoudl be made detectable, but should they also be made configurable? That is a very good question. I personally think we should at least be able to hide things from the user, be it they are sighted or blind.
Anyway, I am getting slightly off-topic here. As far as I know (based on my experience) using abbreviations too much and too stringent makes a website less accessible but does little to nothing for it's usability. At most, it is more visually pleasing.
To answer the question in this topic however (even if I disagree with the use of it) the title attribute should contain the entire definition of the abbreviation and the abbreviation should contain everything that is explained in the title attribute. so the contraction IMO should be placed inside the tag. Simply because tag-content and title-attribute should be made interchangable as well as complemantary.
Share:
| Pent55 wrote: |
| accessible is when when the entire content (text, links, formfields, etc. etc.) can be "read" unambiguously and uncluttered by everyone. |
I'd suggest an accessible website is one where a clear majority users with disabilities are able to complete most tasks and do so in a reasonable amount of time.
| Pent55 wrote: |
| A web site is usable when the user can find what he/she wants or needs (topics, navigation, etc.) without effort. |
I'd suggest a usable site is one where a clear majority of users are able to complete most tasks and do so in a reasonable amount of time.
| Pent55 wrote: |
| If you ask my personal opinion on this topic I would say that:
the best solution would be if visual user agents could display the title attribute before or after the actual element-content (if so instructed) and if aural user agents would disregard the element-content and only read out the title attribute. Or better yet, the other way around. Why not have the standard be: <abbr title="AT">Assistive Technology</abbr>. |
It's rare to find "BBC" written as "British Broadcasting Corporation" which makes the short term more easily understood as well as much shorter. As such, using the short term in this particular case would be of most benefit to all users?
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Share:
I said I was taking a huge shortcut with my definitions. So I agree they may seem to strict as they are. But I think my definitions are right as they stand, even if they are strict. Besides, I was not out on defining the two terms exactly, I was merely pointing out the difference between accesible and usable.
| Quote: |
| So when on the BBC's website, they would always have to write "British Broadcasting Corporation" instead of "BBC"? This is about 10 times longer than the short term. |
So what? I would hate to think of writers and web designers choosing lazy over best practice.
| Quote: |
| which makes the short term more easily understood |
For people from the United kingdom, yes. But accessibility is not just about people with disabilities. A site should be accessible to people from other countries and cultures as well. I guess most people will know what BBC stands for, but are you willing to place a bet on it? When in doubt...etc.
But I am willing to make an exception for the BBC. Why? Because it is a company name which places it in a different ballgame all together.
(to explain, BBC is indeed an abbreviation, but the BBC is more than just a term, it is a company, a concept so it would be better served inside a <dfn> tag for lack of a better solution) ANyway, I can't think of a need to ever write BBCs? Which is waht this topic is about.
But to expand on this topic, what about KLM? It stands for Koninklijke Luchtvaart Maatschappij in Dutch, so what will you put in the title attribute? this or "Royal Airforce Company"? Which would translate to the term RAC. SO are we talking description or meaning here? content accessibility is also about context.
A simple test is to view your code and read from start to finish alt, title and content sequetially out loud, when it doesn't make sense, rethink it.
Share:
| Pent55 wrote: |
|
A simple test is to view your code and read from start to finish alt, title and content sequetially out loud, when it doesn't make sense, rethink it. |
Agreed. Or better still, listen to the page being read -- you'll soon know what needs changing.
Share:
A plural or possessive s is the English language version of the genitive case and plural variations of words found in other languages. "IDs" is one word, not two, as is "ID's". So I guess it's most semantically appropriate to use:
| Code: |
| <abbr title="Identities">IDs</abbr> |
With regards to the slightly off-topic discussion about whether such markup is useful, the realistic question is not whether contractions are more accessible than their unabbreviated equivalents, but rather: given that people will inevitably continue to use ordinary language to communicate, how can we make such language more accessible with markup than it would be without markup?
Also although many abbreviations are less familiar (and so more in need of explanation) and more ambiguous (and so more in need of context or clarification) to a general audience than their fuller equivalents, I don't agree with Pent55 that abbreviations are invariably more inaccessible than other words. The acronym RADAR is an obvious example here. Replacing all instances of the colloquial phrase "on my radar" with "on my radio detecting and ranging" would make the content less accessible, not more. Likewise, I'd personally bet "BBC", although not unambiguous out of context (see the 70 different expansions of "BBC" at Acronym Finder), would be a more internationally recognized term than "British Broadcasting Corporation".
Text-to-speech pronouncing ' as "apostrophy" is a configuration issue. In almost screen reader I've used, you can configure (at least to some degree, and often in great detail) what punctuation is read or not (see for example, punctuation level in the Orca documentation or Determining how Window-Eyes reads punctuation in the Window-Eyes documentation).
As for mispronounced words generally, most screen readers you could add new pronunciations to their pronunciation dictionary. This is more tricky, of course, as it may not be obvious what the correct pronunciation should be.
What nothing in the current technology stack provides is a way for web authors to specify pronunciation information for words in HTML content in a machine readable fashion, so that such additions could be done automatically. Speech CSS cannot properly provide this, for pronunciation can be fundamental to meaning and is not purely presentational. A type attribute for abbr might help, for example:
| Code: |
| type="initialism" |
W3C has developed a markup language for pronunciation lexicons. My hope is that it will one day be possible to apply such lexicons to HTML content using the link element, and specify punctuations inline where necessary using a say attribute, like so:
| Code: |
| <abbr title="World Wide Web Consortium" say="W 3 C">W3C</abbr> |
Share:
I agree totally with benjamin. But let me make clear that I never stated that EVERY abbreviation or acronym should be expanded. RADAR for example has indeed become more of a word than an abbreviation. Again, look at content within context.
How would you mark up (for example):
We at ATS use ATs.
Share:
| Pent55 wrote: | ||
|
I think you need a reality check. Writing "BBC" instead of "British Broadcasting Corporation" is not authoring lazyness. Professional websites are built by people who get paid by the hour, typically. If they spend too long to produce articles, it costs the business too much. The business would need to close down the website to avoid going bankrupt, which would probably be more inconvenient to users than looking up the occassional shortened term.
Indeed, you are using the short form of commonly shortened terms in your own messages. It's not because you are being lazy. Sometimes, the short term is simply the better term!
| Pent55 wrote: |
| How would you mark up (for example):
We at ATS use ATs. |
In terms of meaning, it's all available from context.
"We at" indicates "ATS" is the name of a location or group to which the author is affiliated. A likely situation could be a business website's "About Us" section. Here, "ATS" would be the business name. This name is perhaps expanded elsewhere in the "About Us" section if the user would like more detail.
As an example, consider reading "We at the BBC" while on the British Broadcasting Corporation's website. A user would likely find the short term more recognisable than the long term because that's what their branding uses. In this case there is no benefit to embed a long term with the short term.
"use ATs" indicates "ATs" are some sort of device which a person operates. The spelling of "ATs" indicates this is a plural of "AT", so it is some category of things which a person operates. Context elsewhere on the page may well clarify this further, so even here the short term could be fine. Sadly, asking a search engine what are ATs? or what is an AT? doesn't give many results for things a person could use. So if the page doesn't make clear what it's talking about, using the expanded form or providing a glossary page could be a good idea.
I use quick reality checks like these to make editorial judgements about what term to use. Just like choosing which "normal" words to use and how to structure my sentences.
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Share:
Well, obviously we both have different opinions about this.
But at least we both agree there is no one definitive way of doing abbreviations (or at least I hope so).
Let us return to the topic at had ok?
Do you include the plural in the tag. I think you do because the plural is not always s but sometimes 's and sometimes something different. From wikipedia:
| Quote: |
| Plurals are often formed by doubling the last letter of the abbreviation. Most of these deal with writing and publishing: MS=manuscript, MSS=manuscripts; l=line, ll=lines; p=page, pp=pages; s=section, ss=sections; op.=opus, opp.=opera. This form, derived from Latin is used in Europe in many places: dd=didots. "The following (lines or pages)" is denoted by "ff". One example that does not concern printing is hh=hands. |
and
| Quote: |
| To form the plural of an abbreviation with periods, a lowercase letter used as a noun, and abbreviations or capital letters that would be ambiguous or confusing if the 's' alone were added, use an apostrophe and an s. |
Share:
| Pent55 wrote: |
| But at least we both agree there is no one definitive way of doing abbreviations (or at least I hope so). |
As the topic starter, I don't mind discussion of other aspects of abbreviation happening here. With WCAG 2.0 on its way towards Recommendation status, now is a pretty good time to review these things, imho.
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Share:
| Pent55 wrote: |
| The blog entry you are referring to is about expanding abbreviations and acronyms when <abbr> and <acronym> are used, that is another kind of problem. |
Yes, but if you read the comments, you'll see that the author - a screen reader user - acknowledges that there are some times when an acronym is not expanded.
Two examples used in the discussion are "BBC" and "HTML" - who actually thinks in terms of the "British Broadcasting Corporation" or "Hypertext Markup Language"? The abbreviations have become the thing that carries the meaning.
_________________
Jack Pickard The Pickards Information Services| Blog | Twit
Share:
| benjaminhawkeslewis wrote: | ||
I guess it's most semantically appropriate to use:
|
That's how I understand it too: it's semantically better, but more importantly, it gets 'read out' better too...
_________________
Jack Pickard The Pickards Information Services| Blog | Twit
Share:
All times are GMT
You cannot post new topics in this forumYou cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum