473,326 Members | 2,655 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

Markup, Punctuation and Text-to-Speech

Hi,
I have recently downloaded and experemented with IBM HPR 3.0, and
Opera 8 with text-to-speech, and have come to realise some fairly
annoying issues regarding punctuation marks.

I've found, that when a punctuation mark occurs directly after an
element, both HPR and Opera 8 will read the punctuation mark.

For example, the following:
<p><abbr title="...">HTML</abbr> is an application of
<abbr title="...">SGML</abbr>. However, ...</p>
<p>HTML should be served as <code>text/html</code>.</p>

Will be spoken as:
"HTML is an application of SGML dot However..."
"HTML should be served as text/html dot"

The same result occurs no matter which elements or punctuation marks are
used (except that it speaks "comma" for ",", etc.).

The only solution I can think of to help aural browsers read the
sentence correctly, without unnecessarily speaking the punctuation mark,
is to include it within the element like this:
<abbr title="...">SGML.</abbr>
<code>text/html.</code>

However, I usually don't include puncutation within elements like that
because it's not usually part of the abbreviation or code itself, but
rather part of the sentence as a whole, and it doesn't seem semantically
correct to do so.

So, from a semantic point of view and from an accessibility point of
view, is it better to always include any punctuation within the element
regardless, or is there another way to inform aural browsers of the
correct way to read it, perhaps with stylesheets?

--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://GetThunderbird.com/ Reclaim your Inbox
Jul 24 '05 #1
7 3413
Tim
On Sun, 10 Apr 2005 16:51:07 +1000,
Lachlan Hunt <sp***********@gmail.com> posted:
I've found, that when a punctuation mark occurs directly after an
element, both HPR and Opera 8 will read the punctuation mark.

The only solution I can think of to help aural browsers read the
sentence correctly, without unnecessarily speaking the punctuation mark,
is to include it within the element like this:
<abbr title="...">SGML.</abbr>
<code>text/html.</code>
As you point out, it doesn't belong there. Don't put it there.
However, I usually don't include puncutation within elements like that
because it's not usually part of the abbreviation or code itself, but
rather part of the sentence as a whole, and it doesn't seem semantically
correct to do so.


Correct. Write things correctly. Let faulty software behave faultily.
You'll go mad trying to pander to all of the faults in all of the
browsers-there's masses of them, faults and browsers-and you'll end up with
a page full of crap to accomodate them.

Write to the authors of the software, and point out this fault. They
mightn't have noticed. If they, then, tell you to munge the content to
suit their foibles, bluntly tell them that's wrong.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please delete some files yourself.
Jul 24 '05 #2
In message
<42**********************@per-qv1-newsreader-01.iinet.net.au>, Lachlan
Hunt <sp***********@gmail.com> writes
Hi,
I have recently downloaded and experemented with IBM HPR 3.0, and
Opera 8 with text-to-speech, and have come to realise some fairly
annoying issues regarding punctuation marks.

I've found, that when a punctuation mark occurs directly after an
element, both HPR and Opera 8 will read the punctuation mark.

For example, the following:
<p><abbr title="...">HTML</abbr> is an application of
<abbr title="...">SGML</abbr>. However, ...</p>
<p>HTML should be served as <code>text/html</code>.</p>

Will be spoken as:
"HTML is an application of SGML dot However..."
"HTML should be served as text/html dot"

The same result occurs no matter which elements or punctuation marks
are used (except that it speaks "comma" for ",", etc.).

The only solution I can think of to help aural browsers read the
sentence correctly, without unnecessarily speaking the punctuation
mark, is to include it within the element like this:
<abbr title="...">SGML.</abbr>
<code>text/html.</code>

However, I usually don't include puncutation within elements like that
because it's not usually part of the abbreviation or code itself, but
rather part of the sentence as a whole, and it doesn't seem
semantically correct to do so.

So, from a semantic point of view and from an accessibility point of
view, is it better to always include any punctuation within the element
regardless, or is there another way to inform aural browsers of the
correct way to read it, perhaps with stylesheets?

What do you gain by not including the punctuation mark within the range
of the element as you know it will be spoken if you don't?

Personally, I take the pragmatic approach of *always* including the
punctuation mark within the range of the element to prevent it being
spoken, as I prefer to make it as easy as possible on the listening
audience. Not quite 'correct'? Maybe. But I can live with that.

regards,
--
Jake

Jul 24 '05 #3
On Sun, 10 Apr 2005, jake wrote:
"HTML is an application of SGML dot However..."
"HTML should be served as text/html dot"
What do you gain by not including the punctuation mark within the
range of the element
The dot is not part of that piece of content, and therefore does not
belong inside the element. Most assuredly HTML should not be served
as "text/html.", and there would be a serious problem if anyone
attempted it. Also the abbreviation for SGML is not normally written
with a trailing dot - so the dot is *not* part of its abbreviation, in
fact it marks the end of the sentence, and so the dot should not be
inside the abbreviation markup. It's all part of the general rule to
mark content up consistently, rather than pander to the shortcomings
of one or other browser.
as you know it will be spoken if you don't?
As it happens, I used IBM HPR earlier, and indeed noticed this
shortcoming - but I believe it would be wrong to let the markup be
significantly influenced by it. That way lies madness, and one day
HPR will be improved.
Personally, I take the pragmatic approach of *always* including the
punctuation mark within the range of the element to prevent it being
spoken, as I prefer to make it as easy as possible on the listening
audience. Not quite 'correct'? Maybe. But I can live with that.


For informal contexts, that might be relatively harmless; but when
things get technical, the positioning of a dot could be critical. Just
try (for example) accessing a URL with a superfluous trailing dot (or
conversely, try accessing one which needs a trailing dot, if your
client is too clever for its own good and removes it for you!).

I'd suggest it can often be an improvement both for the visual reader
and the HPR user, if the sentence can be recast so as not to produce
the problematic juxtaposition.

Instead of

HTML should be served as text/html.

one can write something like:

Serve HTML with text/html as [its] content type.

Now there's no doubt about whether the dot belongs as part of the
content type (wrong), or is there as marking the end of the sentence
(as it was intended, but it's nor properly clear in the earlier
formulation, and that goes for visual readers too).
Jul 24 '05 #4
Lachlan Hunt <sp***********@gmail.com> wrote:
I've found, that when a punctuation mark occurs directly after an
element, both HPR and Opera 8 will read the punctuation mark.
That's unfortunate. However, it's a user agent flaw that we cannot
solve in our authoring. It is of such a general nature that even if you
and me (and a few other authors who know and care) took extra trouble
to work around the problem by reformulating our texts or using
illogical markup, the users of such user agents would encounter the
problem on billions of other pages. Besides, it is an inconvenience
rather than an obstacle. So the best, and IMHO only, hope of a cure is
that the people who work with the software will fix the problem.
<p><abbr title="...">HTML</abbr> is an application of
<abbr title="...">SGML</abbr>. However, ...</p>
<p>HTML should be served as <code>text/html</code>.</p>


The examples are somewhat different from each other. In the latter
paragraph, the <code> markup affects, in practice, the rendering, and
it may help an automatic translator like BabelFish to avoid trying to
translate "text/html". The <abbr> markup, on the other hand, is more
questionable: usually no tangible benefits, but some potential
problems.

In particular, if you use <abbr> just in order to use a title="..."
attribute to specify the expansion, you are mostly doing things wrong
way. Explanations should be explicit, or given with links.
Unfortunately the WCAG 1.0 tells us to use <abbr> or <acronym> for all
abbreviations and acronyms, which is worse than waste of time.

Avoiding redundant or harmful markup doesn't solve the original problem
of course; there are many situations where a markup element is needed
in a context where it is immediately followed by a punctuation mark.
Trying to avoid them or putting the mark inside the element would
create more problems than it would solve. (For example, the element
would often be an <a> element that sets up a link. Putting a
punctuation mark at the end of a link text when the mark does not
belong there would create several small problems.)

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Jul 24 '05 #5
Jukka K. Korpela wrote:
Lachlan Hunt <sp***********@gmail.com> wrote:
I've found, that when a punctuation mark occurs directly after an
element, both HPR and Opera 8 will read the punctuation mark.
That's unfortunate. However, it's a user agent flaw that we cannot
solve in our authoring.


Ok, good point. I guess, just like I normally wouldn't try to fix a
rendering bug for IE with markup hacks, I shouldn't try it with any
other browser either. Although, since this one seems to affect
accessibility a bit more, I thought it would be nice to at least attempt
a fix.
the users of such user agents would encounter the problem on billions
of other pages. Besides, it is an inconvenience rather than an obstacle.
Very true, so I'd guess they'd be used to it and they would at least
understand my intent, despite the minor annoyance.
In particular, if you use <abbr> just in order to use a title="..."
attribute to specify the expansion, you are mostly doing things wrong
way. Explanations should be explicit, or given with links.
Do you mean, that:

<abbr title="Standard Generalised Markup Langauge">SGML</abbr>

is an incorrect use of abbr, unless I make it a useful link or have
provided further explanation within the document?
Unfortunately the WCAG 1.0 tells us to use <abbr> or <acronym> for all
abbreviations and acronyms, which is worse than waste of time.
I agree with your point about not using <abbr> for every single
abbreviation. To do so is more annoying than beneficial, not to
mentiona pain to markup a document with so many.

In fact had I done so with my latest blog entry, I would have ended up
with around 100 <abbr> elements in the whole document, given all the
times I mentioned SGML, XML, HTML, XHTML, etc. I now tend to only
markup abbreviations where the intended audience is not expected to
understand what they are, and generally only for the first occurance of
each in the document.
(For example, the element would often be an <a> element that sets
up a link. Putting a punctuation mark at the end of a link text when
the mark does not belong there would create several small problems.)


What small problems could it create for a link? Of all the elements, I
thought <a> would be one that could get away with such a hack, without
being too semantically incorrect.

--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://GetThunderbird.com/ Reclaim your Inbox
Jul 24 '05 #6
Lachlan Hunt wrote:
Jukka K. Korpela wrote:

[...]
(For example, the element would often be an <a> element that sets
up a link. Putting a punctuation mark at the end of a link text when
the mark does not belong there would create several small problems.)

What small problems could it create for a link? Of all the elements, I
thought <a> would be one that could get away with such a hack, without
being too semantically incorrect.


Gotta agree with you there. The content of an element is irrelevant
in nearly every case, it is the attributes that are important.

While purists may rage against the semantics of putting periods where
they aren't 'supposed' to be, your users may well appreciate your
efforts.

When all else fails, use Alan's solution.
--
Zif
Jul 24 '05 #7
Lachlan Hunt <sp***********@gmail.com> wrote:
Do you mean, that:

<abbr title="Standard Generalised Markup Langauge">SGML</abbr>

is an incorrect use of abbr, unless I make it a useful link or have
provided further explanation within the document?


More or less so; though I would say "useless" or "a little worse than
useless" rather than "incorrect". The harm comes from the author's idea
that the attribute _helps_ users. Actually, it is invisible to the vast
majority of users (including all IE users). And writing such attributes
in effect makes authors escape the task of actually explaining the
abbreviations they use or at least pointing to explanations.

Besides, it's "Standard Generalized Markup Language", so you made two
typos. This is rather symptomatic: attribute values contain much more
typos than normal text - partly because even the author himself does
not normally see them as document content.
Unfortunately the WCAG 1.0 tells us to use <abbr> or <acronym> for
all abbreviations and acronyms, which is worse than waste of time.


I agree with your point about not using <abbr> for every single
abbreviation.


Besides, WCAG 1.0 does not really tell us whether we should do so or
just for first occurrences. The general idea might be that browsers are
expected to understand things from the markup for the first occurrence.
I don't think any browser makes any attempt at that. Moreover, WCAG 1.0
or the W3C in general still hasn't told us what the **** is the
difference between acronym and abbr. But the W3C HTML working group
tends to throw away acronym. So you can choose between a tag that is
not supported and a tag that will probably become obsolete.

Or you can just regard acronym and abbr as useless, or use them for fun
only (with some risks).
(For example, the element would often be an <a> element that sets
up a link. Putting a punctuation mark at the end of a link text
when the mark does not belong there would create several small
problems.)


What small problems could it create for a link? Of all the
elements, I thought <a> would be one that could get away with such
a hack, without being too semantically incorrect.


Links are what makes HTML hypertext. They should be used properly, not
hacked. Think about a speech-based user agent reading all links on a
page, on user request, saying "period" or "full stop" at the end of
some links. Think about an indexing program that needs to treat
"SGML" and "SGML." as separate links (since we know that "." can be
part of an expression and make a difference). Think about user
confusion if the user is careful enough to look at the link text and
wonder why the punctuation is included. He won't know your reasons, and
should not need to ask.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Jul 24 '05 #8

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
by: MarionEll | last post by:
--------------------------------------------------------- ************* Call for Participation ************** ************ Late Breaking News ************* *********** Extreme...
0
by: Andreas Prilop | last post by:
In plain text, the letter "a" followed by combining mark U+0300 should be displayed as "à", letter "a" with grave accent. Two or more Arabic letters in succession should join. What should happen...
2
by: frazer | last post by:
how do i ensure the user always enters alphanumeric characters in my text box. no spaces or punctuations?
13
by: Adrienne Boswell | last post by:
In the site I am redoing, I am frequently running into this screnario: Tel: (818) 555-1212 Fax: (818) 555-1234 where the tel and fax should be bold to stand out. Currently, I am using span with...
12
by: Limeburner72 | last post by:
Hi, how can I count the number of punctuation characters within a text file prompted from the keyboard?
1
by: nickyeng | last post by:
I have done the following code, i just couldn't figure out why it can erase the punctuation in the end of each word(strr variable) ? i got this when i run it:...
12
by: Torsten Bronger | last post by:
Hallöchen! Some LaTeX users in Aachen thought about a general-use markup language this spring. I wrote some code and a rough project description, however, we could need some help. If you are...
0
by: Joshua Kugler | last post by:
Michael Mabin wrote: Several here: http://pypi.python.org/pypi?%3Aaction=search&term=wiki&submit=search I'm sure you could find a good one, and add your own markup if needed. j
3
by: _Who | last post by:
In the .aspx I have <p runat="server" id="qq" </p> and in the aspx.vb I have Protected Sub qq_Init(ByVal sender As Object, ByVal e As System.EventArgs) Handles qq.Init strContents =...
8
by: Bubbs | last post by:
I keep getting this exception when i run the program. It is driving me insane. Does anyone know whats wrong and how do i fix this! System.Windows.Markup.XamlParseException was unhandled Message:...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.