WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: abbreviations

for

From: Dan Conley
Date: May 28, 2010 7:57AM

If we can start punishing users for their actions then I need to go back
through my site and remove all the IE hacks and concessions I've had to
make.

If they print the page then they don't get the abbreviations, yes. But
that's why it should be expanded on first use. If they read it on the
page then there's extra functionality. By your logic we shouldn't link
to anything because tapping on the printed paper won't take them anywhere.

There's functionality which enriches the content but which still conveys
the original intent if ignored or not displayed. Isn't that the whole
point of accessibility?

Dan Conley
Information Specialist
Center for International Rehabilitation Research Information and
Exchange (CIRRIE)
University at Buffalo, Health Sciences Library B6
Phone: (716) 829-5728
<EMAIL REMOVED>
http://cirrie.buffalo.edu

On 5/28/2010 8:48 AM, Geof Collis wrote:
> So whose fault is it if they dont start at the beginning of the
> content? That doesn't make any sense. Perhaps we should have a
> tag that says start here in case you miss any
> accessibility features on this page?
>
> If people use the abbr and acr tags, what happens if someone prints
> off the page? Copies from one medium to another? The real meaning
> doesn't go with it so how does that help?
> At 08:21 AM 5/28/2010, you wrote:
>> > I have an idea, why not just use the current example that I posted,
>> > expand the abbreviation in the first instance and be done with it. :O)
>>
>> And then someone skips to an anchor halfway down the page and misses it.
>>
>> I think what's perhaps the most important thing I've gotten out of this
>> discussion is that many people don't care about abbreviations, and those
>> people have and use the ability to ignore them completely. The abbr tag
>> isn't being forced down anyone's throats (which was my initial fear).
>>
>> There are some instances where an abbreviation isn't necessary. My
>> example of HIV in an article titled Human Immunodeficiency Virus is a
>> pretty obvious example. But I'm very hesitant to say I'm going to
>> approach this on a case by case basis, because then I declare myself the
>> gatekeeper of what's 'obvious' or not, which won't be the same from
>> person to person.
>>
>> If something is an abbreviation, shouldn't it by definition be given the
>> abbreviation markup? If you don't like the underline it can be styled
>> away. If people ignore it then that seems, for the most part, to be by
>> their design (and if not, then in each of the articles I work on and in
>> any well written document I'd expect there to be the 'expand on first
>> use' practice anyway)
>>
>> Dan Conley
>> Information Specialist
>> Center for International Rehabilitation Research Information and
>> Exchange (CIRRIE)
>> University at Buffalo, Health Sciences Library B6
>> Phone: (716) 829-5728
>> <EMAIL REMOVED>
>> http://cirrie.buffalo.edu
>>
>> On 5/28/2010 7:36 AM, Geof Collis wrote:
>>> I have an idea, why not just use the current example that I posted,
>>> expand the abbreviation in the first instance and be done with it. :O)
>>>
>>> At 12:23 AM 5/28/2010, you wrote:
>>>> Jukka K. Korpela wrote:
>>>>>
>>>>> On the other hand, using<abbr> or<acronym> markup would help
>>>>> remarkably
>>>>> little if at all in reducing confusion. To begin with, the vast
>>>>> majority of
>>>>> people use browsing software that either ignores such markup completely
>>>>> or
>>>>> uses it in misleading ways, like underlining the element's content in a
>>>>> manner that suggests that it is some kind of a link, even though it
>>>>> isn't.
>>>>
>>>> Hi Jukka,
>>>>
>>>> How/what would you propose be done instead? If we can agree that a
>>>> mechanism that aids in disambiguation is a good thing - yet currently
>>>> <abbr> is failing at that - is there a better way? Should user agents do
>>>> more, or should we look to another mechanism instead? With on-going work
>>>> within HTML5, and an accessibility Task Force at the W3C (that involves
>>>> browser makers) currently very active, could a better solution be put
>>>> forward? Now is the time to specifically define what we need and what we
>>>> should have.
>>>>
>>>> Does anyone on this list have any ideas?
>>>>
>>>> JF
>>>>
>>>>