JAWS and the summary attribute
emma...@gmail.com
I've just marked up a table using the summary attribute as follows:
<table summary="A confirmation of all personal details entered into the
previous form">
However, when I run JAWS 7.0 over this it says "untitled table"
Have I done something wrong? Is this normal behaviour? Is there a
setting in JAWS configuration that I'm missing?
Thanks
M
Sander Tekelenburg
emma...@gmail.com wrote:
> I've just marked up a table using the summary attribute as follows:
>
> <table summary="A confirmation of all personal details entered into the
> previous form">
>
> However, when I run JAWS 7.0 over this it says "untitled table"
Does any other screen reader do anything useful with the summary
attribute? I've been testing some of these things recently and it looks
like screen readers tend to completely ignore most of the accessibility
features HTML and CSS offer. (Makes you think, doesn't it?)
--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>
Mac user: "Macs only have 40 viruses, tops!"
PC user: "SEE! Not even the virus writers support Macs!"
Jake
Tekelenburg <us...@domain.invalid> writes
>In article <1158245615.0...@e3g2000cwe.googlegroups.com>,
> emma...@gmail.com wrote:
>
>> I've just marked up a table using the summary attribute as follows:
>>
>> <table summary="A confirmation of all personal details entered into the
>> previous form">
>>
>> However, when I run JAWS 7.0 over this it says "untitled table"
>
>Does any other screen reader do anything useful with the summary
>attribute? I've been testing some of these things recently and it looks
>like screen readers tend to completely ignore most of the accessibility
>features HTML and CSS offer. (Makes you think, doesn't it?)
>
HPR 3.04 will announce the contents of the 'summary' as it comes across
it in 'read-through' (Items reading) mode.
In 'Tables jump' mode, when using the right-arrow it will move from
table-to-table, announcing the content of the table summary as it does
so.
--
Jake ('Ja...@gododdin.demon.co.uk' -- just a 'spam trap' address)
Sander Tekelenburg
Jake <Ja...@gododdin.demon.co.uk> wrote:
> In message <user-34F13D.0...@textnews.euro.net>, Sander
> Tekelenburg <us...@domain.invalid> writes
> >In article <1158245615.0...@e3g2000cwe.googlegroups.com>,
> > emma...@gmail.com wrote:
> >
> >> [...] <table summary="A confirmation of all personal details entered into the
> >> previous form">
> >>
> >> However, when I run JAWS 7.0 over this it says "untitled table"
What I forgot about earlier: are you sure your mark-up is correct? If it
isn't, there's no predicting what might happen, because browsers will
try to guess what you mea -- no way to be sure they'll guess right.
Btw, the string "untitled table" suggests to me that it might be
referring to the table's caption element, not to the summary attribute.
> >Does any other screen reader do anything useful with the summary
> >attribute? [...]
>
> HPR 3.04 will announce the contents of the 'summary'
Excellent. What exactly is "HPR" and where can I find out more about it?
[...]
> In 'Tables jump' mode, when using the right-arrow it will move from
> table-to-table, announcing the content of the table summary as it does
> so.
Cool. That suggests it might be capable of doing more useful things with
tables. Does it for instance which header cell(s) referr to the current
data cell? That connection is of course available implcitly, but HTML
allows authors to make it explicit (through headers, scope and abbr
attributes), yet so far I haven't found any tools that make use of such
info.
Samuel Proulx
> Excellent. What exactly is "HPR" and where can I find out more about it?
project, for the use of those blind users who lack a screen reader, or
for use on library or other public computers that need an accessible web
browser. The official page from IBM is at:
http://www-3.ibm.com/able/solution_offerings/hpr.html
a demo is available from that page.
--
Samuel Proulx
mailto: sam...@interfree.ca
http://fastfinge.livejournal.com
Cursor: An expert in four-letter words.
Veli-Pekka Tätilä
As there are multiple posters here, I'll experiment with using different
letters for each one. So:
E, J, S, V: Emma, Jake, Sander, Veli-Pekka
Here we go:
E: I've just marked up a table using the summary attribute as follows:
However, when I run JAWS 7.0 over this it says "untitled table"
S: Does any other screen reader do anything useful with the summary
attribute? I've been testing some of these things recently and it looks like
screen readers tend to completely ignore most of the accessibility features
HTML and CSS offer.
V: Yeah, in addition to Voice Over other readres have issues as well. At
least with Dolphin products, such as Supernoava 7, it appears that a lot of
accessibility info is read only optionally. Titles are not read by default,
for example. More surprisingly Supernova does not, and I suppose this
extends to Jaws and Window Eyes, respect any attributes in aural CSS. That
is if you'd like a certain number to be read as digits or emphasis as a
higher pitch, none of the readers do that, even if instructed by the Web
page author.
The issue is that the readers read the document the browser shows on screen
which doesn't convey the aural CSS styles. What would be needed, as far as I
can see, was an interface for Exchanging aural CSS information in a standard
way between screen reader and browser Software.
J: HPR 3.04 will announce the contents of the 'summary' as it comes across
it in 'read-through' (Items reading) mode.
V: Yeah, I've noticed HPR does a pretty good job all in all, thanks for
letting us know how it works. But to be really pedantic, it is a speaking
browser not a screen reader. On a positive note, this might also mean that
it is able to respect aural CSS like screen readers should. Has anyone
tested this?
I found some sample source code for aural CSS simply by Googling for aural
css example without any quotes.
--
With kind regards Veli-Pekka Tätilä (vta...@mail.student.oulu.fi)
Accessibility, game music, synthesizers and programming:
http://www.student.oulu.fi/~vtatila/
Sander Tekelenburg
Samuel Proulx <sam...@interfree.ca> wrote:
> Sander Tekelenburg wrote:
> > Excellent. What exactly is "HPR" and where can I find out more about it?
> HPR, fully known as IBM Home Page Reader
Ah, right. I can't test that 'cause I have no appropriate Windows box
available. Do you know to what extend, if any, it supports aural CSS?
Brian Gaff
find all tables confusing in the first place. They are not always a good way
to present data clearly when you have to navigate them and tend, as I do to
forget the 'plot' of the table half way down!
Brian
--
Brian Gaff - bri...@blueyonder.co.uk
Note:- In order to reduce spam, any email without 'Brian Gaff'
in the display name may be lost.
"Sander Tekelenburg" <us...@domain.invalid> wrote in message
news:user-5444E5.1...@textnews.euro.net...
Jake
<vta...@mail.student.oulu.fi> writes
True -- although you can really think of it as a screen reader limited
to Internet-related functionality (Web pages, email, pdf files, flash
objects, etc.)
>On a positive note, this might also mean that
>it is able to respect aural CSS like screen readers should. Has anyone
>tested this?
>
No. Not aural CSS.
When I last looked into it, the only reader that supports aural CSS is
Emacspeak -- but things might be different now. Isn't there some work
being done to make Opera support aural CSS?
>I found some sample source code for aural CSS simply by Googling for aural
>css example without any quotes.
>
--
Jake
Sure. It fully supports table markup -- headers, caption, scope,
summary, header abbreviations -- as well as providing the usual reader
functionality of full table navigation.
Sander Tekelenburg
Jake <Ja...@gododdin.demon.co.uk> wrote:
[..]
> Isn't there some work
> being done to make Opera support aural CSS?
Yes. See <http://www.opera.com/docs/specs/css/>.
Sander Tekelenburg
Jake <Ja...@gododdin.demon.co.uk> wrote:
[...]
["HPR"]
> It fully supports table markup -- headers, caption, scope,
> summary, header abbreviations -- as well as providing the usual reader
> functionality of full table navigation.
Thanks. That sounds quite nice. I'll try to test it some time.
Sander Tekelenburg
"Brian Gaff" <bri...@blueyonder.co.uk> wrote:
> This thread is all very fine and dandy, but myself, and some people I know,
> find all tables confusing in the first place.
That's exactly what this thread is about: how to make it easier to
navigate tabular data.
> They are not always a good way
> to present data
Well, when the data is not tabular, I agree. But when it is tabular I
don't see how it would make sense to mark it up as something else.
> clearly when you have to navigate them and tend, as I do to
> forget the 'plot' of the table half way down!
Yeah, that's why authors should provide enough information to make it
possible for your browser to provide you with the plot at any moment, no
matter how deep you have drowned in the table. This thread is about how
to offer such information as an author, and about in how much browsers
and screen reader make such information available or ignore it.
Jukka K. Korpela
>> They are not always a good way
>> to present data
>
> Well, when the data is not tabular, I agree. But when it is tabular I
> don't see how it would make sense to mark it up as something else.
I understood Brian Gaff's comment so that it was about the inherent problems
with tables. There are things that people can and should do when setting up
tables, but there's more than that, and the primary decision should be
whether a table is used in the first place. There is a lot of data that is
logically tabular, but this does not mean that a table is always the best or
only way to present it.
It is often easy to show a table and expect the reader to see the essential
point from it, perhaps glimpsing over a column that immediately catches the
eye and strikingly expresses the idea. But this won't work for blind people,
and it may fail for many other people as well, e.g. people with low vision
or very small devices so that they can see just a small portion of the table
at a time. It also fails for people with cognitive difficulties that prevent
them from seeing the obvious, so to say. Actually, even emotional things are
involved: many people just hate piles of numbers or are afraid of them.
The summary attribute might be of some help, since it could be used to
explain the basic idea of the table and to say things that might be obvious
to an average person from a look at the table as a whole but not obvious at
all without that. Whether this matches the definition and intended use of
the attribute is debatable. Moreover, we have the problem that many people
who would benefit from the text in the attribute simply miss it because
their browser ignores it. So authors shouldn't really rely on the attribute,
and what is the point then? Isn't it better to explain things before the
table in normal page content so that everyone has easy access to it? If this
is so, is there much reason to ask software vendors to add or improve
support to the summary attribute?
Moreover, for many tables, it would be better to spell out their essential
content, presenting it as normal text. This could be followed by a table, or
a link to a table, so that the minority that might be interested in the
details can check them and other can just skip the table. Think about a
typical small table that is presented to show, for example, that trade
between Syldavia and Borduria has increased about five percent in the
average each year during the last ten years. I think you should normally
write first such a summarizing statement and then consider whether a
detailed table is needed at all after it.
Things are different if the table as such is the essential content. For
example, a table containing the names of countries and capitals could be
presented to let people check such things out. There's no point in a
summary - as normal textual content or as the value of a summary attribute -
except as an explanation of the content and structure of the table, and this
wouldn't really be a summary but a legend. In such cases, on the other hand,
it could be better to offer a search form that lets the user enter some key
word or words and have some result displayed, as extracted from a data base.
If you want to know the capital of Syldavia, it would probably be easier to
type "Syldavia", hit enter, and get an answer to the specific question,
instead of scanning through a table with two hundred or so rows to find the
information. The use of a summary attribute or other accessibility-enhancing
markup for a table is of much smaller significance.
--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/
Brian Gaff
Details as description, or discussion
details in tabular form and let the user decide.
I'm always banging on about this in my roll as a person who puts stuff on
tape. I keep on hammering the council when designing leaflets, to add a
description for the reader, so he or she is not faced with trying to
describe a table on the hoof, but is this advice understood and heeded? Of
course its not, ever.
Brian
--
Brian Gaff....Note, this account does not accept Bcc: email.
graphics are great, but the blind can't hear them
Email: bri...@blueyonder.co.uk
______________________________________________________________________________________________________________
"Jukka K. Korpela" <jkor...@cs.tut.fi> wrote in message
news:nu2Qg.15872$Uf2...@reader1.news.jippii.net...
emma...@gmail.com
> What I forgot about earlier: are you sure your mark-up is correct?
most definitely yes, it is correct.
> Btw, the string "untitled table" suggests to me that it might be
> referring to the table's caption element, not to the summary attribute.
There is also a caption on the table.
Weirdly, now that I've moved the table below other content (i.e. it is
not first on the page) it is not announcing "untitled table" but
neither is it announcing the summary attribute.
Samuel Proulx
> Ah, right. I can't test that 'cause I have no appropriate Windows box
> available. Do you know to what extend, if any, it supports aural CSS?
I own a full copy of hpr. If you'll link me to a page using the
techniques in question, I'll let you know what it does.
--
Samuel Proulx
mailto: sam...@interfree.ca
http://fastfinge.livejournal.com
"Less then a thimble-full of iodine divides the intellectual from the
imbecile. Of which phenomenon I shall forthwith attempt a
demonstration." -- Gull, in FROM HELL #2
Sander Tekelenburg
"Jukka K. Korpela" <jkor...@cs.tut.fi> wrote:
[...]
> I understood Brian Gaff's comment so that it was about the inherent problems
> with tables.
Yes, that's how I understood it too :) I just meant to make clear that
some data just *is* tabular. (And although I didn't spell it out, I
meant to suggest that UAs may need to do a better job at making tables
accessible.)
You're right though to point out that, as with most things, there are
exceptions, situations in which tabular data doesn't need to (only) be
presented as such.
[...]
> It is often easy to show a table and expect the reader to see the essential
> point from it, perhaps glimpsing over a column that immediately catches the
> eye and strikingly expresses the idea.
Right. For such cases, relying purely on the table to get the point
across isn't ideal. As you say, expressing "the idea" textually and
offering the table only as additional data is better in such cases. Also
for sighted users, who can somewhat similarly "get lost" when tables are
so long they need to scroll through them. (Too bad that current browsers
still aren't good at presentating static thead and tfoots, with
scrollable tbodys.)
[...]
[summary attribute]
> we have the problem that many people
> who would benefit from the text in the attribute simply miss it because
> their browser ignores it.
Right. IMO it's up to users to insist on better user-agents.
> So authors shouldn't really rely on the attribute,
> and what is the point then? Isn't it better to explain things before the
> table in normal page content so that everyone has easy access to it?
I think that may depend on the situation. I can imagine that in some
situations providing such a summary marked up as regular text, before
the table can have its negative effects. For example, if the table's
data itself will be immediately clear to sighted users. Because after
all, the more information you give people, the more effort it will take
them to digest it.
Similarly, I expect a speech browser to allow users to jump from block
to block within a Web page, to help them get an overview. In that
situation, when hitting upon a table, a summary attribute should be
useful, because the browser cannot know that some text marked up as a
regular paragraph before the table relates to the table.
To put that in more general terms: a deeper problem with this approach
is that there is no way in HTML to mark that preceeding text up as
something belonging to the table below it.
> If this
> is so, is there much reason to ask software vendors to add or improve
> support to the summary attribute?
Well, how about when you've navigated deep inside the table and gotten
so lost you don't know what the table is about anymore? Wouldn't it be
useful to be able to get the contents of tha summary attribute right
there, without having to move all the way up again first?
In that same situation, being able to always have access to the table
headings that refer to the current cell would similarly be useful I'd
think.
> Moreover, for many tables, it would be better to spell out their essential
> content, presenting it as normal text. This could be followed by a table, or
> a link to a table, so that the minority that might be interested in the
> details can check them and other can just skip the table.
Agreed for such cases, yes.
> Think about a
> typical small table that is presented to show, for example, that trade
> between Syldavia and Borduria has increased about five percent in the
> average each year during the last ten years. I think you should normally
> write first such a summarizing statement and then consider whether a
> detailed table is needed at all after it.
Agreed. Nice example.
> Things are different if the table as such is the essential content. For
> example, a table containing the names of countries and capitals could be
> presented to let people check such things out.
Right. I am working on the accessibility of such a table at the moment,
so it sort of momentarily slipped my mind that there are other
situations.
[...]
> it could be better to offer a search form that lets the user enter some key
> word or words and have some result displayed, as extracted from a data base.
Yes, allowing people to limit the amount of data can help make it easier
to get/keep an overview. (Although then you get into the discussion of
how to make such a filter nicely accessible ;))
Sander Tekelenburg
Samuel Proulx <sam...@interfree.ca> wrote:
> Sander Tekelenburg wrote:
> > Ah, right. I can't test that 'cause I have no appropriate Windows box
> > available. Do you know to what extend, if any, it supports aural CSS?
>
> I own a full copy of hpr. If you'll link me to a page using the
> techniques in question, I'll let you know what it does.
That would be great. The page in question is not yet publicly available
however. If you're into moving this to a more private channel let me
know and I'll mail you and give you access to it. Otherwise, I hope I
can take you up on your offer in a couple of weeks, when the site goes
public.
Samuel Proulx
> That would be great. The page in question is not yet publicly available
> however. If you're into moving this to a more private channel let me
> know and I'll mail you and give you access to it. Otherwise, I hope I
> can take you up on your offer in a couple of weeks, when the site goes
> public.
field of all of my usenet posts is, in fact, my real email address.
Feel free to contact me any time. I believe in spam filtering and
reporting, not trying to hide from the bad guys in hopes they don't find
you.
--
Samuel Proulx
mailto: sam...@interfree.ca
http://fastfinge.livejournal.com
Better to remain silent and be thought a fool than to speak out and
remove all doubt. - Abraham Lincoln
Sander Tekelenburg
Samuel Proulx <sam...@interfree.ca> wrote:
> Sander Tekelenburg wrote:
> > Ah, right. I can't test that 'cause I have no appropriate Windows box
> > available. Do you know to what extend, if any, it supports aural CSS?
>
> I own a full copy of hpr. If you'll link me to a page using the
> techniques in question, I'll let you know what it does.
Sorry it took so long. Can I still lure you into trying hpr on the site?
It's publicly available now, at <http://webrepair.org/>.
If you're into it, I'd very much like you to look at the entire site.
But the table accessibility stuff (which triggered this thread
originally), is at
<http://webrepair.org/02strategy/03known%20systems.php>.
TIA