Hello Nathalie,
A couple of things:
1) You don't have to have a single glossary database for all your documents.
It is quite reasonable to break it up into glossaries that are
topic-appropriate.
2) Title was what the W3C consortium recommend at one time for the expansion.
I have
not kept up with it for a while, since dropping out of the accessibility
police in
the writing group I worked with. If you want to have other behavior, such
as
expanding it inline, it is a matter of slightly different coding to make
it work.
I have noticed that there is a lot of variability in what screen readers
actually
do with the same source markup and find that somewhat frustrating. It is
similar
to the CSS wars among browsers in the early days of CSS (when we had to
use a
JavaScript to load the appropriate CSS file based on the platform and
browser
being used (and even version of browser in some cases). There is some
chatter on
the Web that indicates using acronym vs. abbr can lead to different
behavior for
the title.
3) If you are worried about the size of a glossary database, the same thing
can be
done with a glossary section in a book (or other document). The downside
is that
you have to repeat the glossterm in each document it is used in, but the
upside is
you can customize the glossary appropriately in a manner appropriate to a
specific
context. I wrote a simple script to extract terms from a master glossary
and
add them to a glossary which was then made part of the book itself, rather
than
using the glossary database (specifically to avoid problems with render
time and
creeping changes in a glossary -- you don't always want the most current
version
of glossary entries every time a document is built).
4) The expansion was added to the acronym element, as recommended by W3C for
expansion of acronyms. A title on the anchor element (the a) would be
associated
with the link destination rather than with the acronym.
As a friend of mine frequently says, "I admire your problem."
Good luck solving it.
Best Regards,
Larry Rowland
-----Original Message-----
From: Nathalie Sequeira [mailto:[email protected]]
Sent: Thursday, November 11, 2010 7:47 AM
To: [email protected]
Subject: Re: [docbook-apps] acronyms, abbreviations, definitions
Hi Larry,
> The advantage of storing it centrally in the glossary is that the expansion
> doesn't have to be added to every instance of the acronym (while convention
> says it only needs to be expanded at "first occurrence," in electronic media,
> determining the "first occurrence" for a reader can be difficult so we
> frequently used an acronym tag the first time an acronym was used in a
> topic). It also provides a mechanism for explaining what the expanded
> acronym means, since expansion is not always sufficient to explain why it
> matters.
>
At first I found the prospective offered by the glossary database
feature rather enticing, exactly because of the repetitiveness (during
the production phase) of adding the extended version - ideally to each
- instance of an abbreviation/acronym.
So the idea of having an external glossary that is run over a text in
which the acronyms/abbreviations are also marked as glossterms (which,
when explanation is necessary, can also be linked to a "real" glossary -
slick!), and xslt'ing the lot into nicely formed, fully functional
XHTML-Elements would be something that could greatly enhance the reading
experience of online versions, while in PDF/print versions, just the
classical glossary could be output...
However, the question arises for me how viable this is when dealing with
a very large text base.
(in my case I'm working on a growing online library with currently 1600
texts - from short articles to whole books - dealing with diverse
aspects of "disability" on a variety of levels).
- I'd be afraid that the glossary itself would soon grow to dimensions
that are not so easily to be edited anymore.
- And, as I understood it, the text is processed in loops for each
single glossary term (even if 3/4 of them are not relevant for the text
in question). Since our HTML-versions are cached, this would not happen
every time the pages are loaded, but still... wouldn't that create an
enormous processing overhead?
Asked the other way around, how large is the text base you apply this
technique to?
Also, I'm not sure about how your output looks:
> Getting expansion on hover or similar is slightly trickier, but not a major
> stretch (the match to the glossentry is already being made by the extended
> glossterm auto link code) by adding a title attribute with the content of the
> glossterm to the anchor element around the acronym in the output (at least in
> HTML).
Do I understand rightly that you are adding the expansion as a title to
the <a> element?
I hate to say so, but I am just currently being made aware of the fact
that "title" does not work reliably on links in screen readers.
Apart from the fact that the expansion is no longer attributed to the
acronym itself, but rather becomes additional information about the
content being linked to...
So what may look the same for sighted people is a completely different
(and possibly invisible) creature for screen reader output.
This mechanism should thus actually insert the glossterm into acronym to
make it fully functional (perhaps only creating the glossary link when
there is, in fact, an additional explanation...).
Thanks for the interesting input :)
Nathalie
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
