Re: Calendar markup - review please?

Taking a few responses together...

At 17:05 2004-10-28, Sailesh Panchang wrote:
>Ref http://iamback.com/blog/
>Works pretty  well with JAWS... but:
>- the default option for JAWS is to read screen text  for links and not 
>title. So only when I realized that the << and >> links  before and after 
>current month's calender  had title set on them, I switched to title 
>reading and then it announced  Sept and Nov because current month was Oct. 
>And before I thought about titles,  I just clicked on the links and 
>discovered that they take me to previous and next month.  One alternative 
>is to have an image link. The image can be of << and >> signs and the alt 
>can be previous month and next month respectively. Then titles are not needed.

Brilliant!
I knew the >> and << links were a potential problem - but not exactly how 
(and I carefully avoided posing leading questions!). Your description makes 
it clear.
In addition, I generally work from the principle "don't use an image when a 
text link will do" - but here you give us a very plausible example why (and 
when) an image link instead of a text link may actually benefit screen 
reader users. That's a real eye opener (pun not intended) - thanks Sailesh!

(Would you have thought of asking JAWS to read title attributes without my 
introduction though? To what extent is this due to "experienced JAWS user" 
and to what extent "follows from the description" (of calendar as navigation)?)

BUT....

At 17:39 2004-10-28, Martin Stehle wrote:
> > How would *you* mark up a calendar?
>
>I would use a data table of course. For your calendar on your travel
>site I recommend:
>* Month's name as CAPTION. This means also means:
>* taking the pre-month and next-month links out of the table
>   structure, e.g. under the table.

This also sounds like an excellent suggestion - but now I'm getting into 
trouble. I see two excellent ideas that seem to be somewhat contrary:

- I like the idea of using the current month as a 'caption'
- taking links to previous and next month out of the table makes some sense 
too, except...

While one table ("calendar page" for a month) is clearly "about" a specific 
month (which is where the caption fits in nicely) some of the *dates* 
(numbers) shown will actually belong to the previous or next month. I've 
tried to translate that by tying those dates to the *links* to those months 
using the 'headers' attribute, which (technically) works because the links 
to those are _in_ the table.

Now, when I take those out of the table, as you suggest (and I could still 
use image links, as Sailesh suggests), how do I tie those dates to their 
respective months?

One idea that comes up is to maybe put the "previous month" and "next moth" 
in a 'tfoot' row group so I'd still have cells (with an id) that I could 
refer to with a 'headers' attribute.

Thoughts, anyone?

Sailesh Panchang also wrote:
>- While reading down a column JAWS reads headers ok. But  only for col#2 
>i.e. Tuesday, it reads the dates in first column as row header. So it 
>reads 11 as row header for 12 and 18 as row header for 19.. In other 
>columns I did not face this problem.

This is weird - it sounds like a JAWS bug to me... could it be? There _are_ 
no row headers in my table, so it seems like JAWS is just making them up.
Could this be a function of how you're actually *using* JAWS on the 
calendar, or put differently: can you navigate the calendar table (and use 
it as a navigation tool) while avoiding JAWS making up these row headers? I 
carefully put in the headers attribute (for each date cell) so it refers to 
both the month and the weekday - can JAWS make use of that, and / or 
somehow tell you those attributes exist?

Observations with other AT would be welcomed here.

>In all it is very good.
>Sailesh Panchang

Thanks!
(Not perfect, but it will never be. Still trying to make it better, though.)

(Martin again:)
>* In your table the first line are the the week days. You wrote them
>   in a short form. I would add ABBR tags to them so a screen reader
>   user can hear their meanings. In this case I recommend using the
>   abbr-Attribut for the TH for the opposite purpose: to expand the
>   short terms. Further step: Put them in THEAD.

I agree they should go in the thead if its current content is taken out - 
they'd be the only header left.

The suggestion of using 'abbr' attributes to *expand* rather than 
abbreviate a header is interesting. I actually saw that in one example in 
an article but was having some doubts - it would seem to be contrary to the 
(stated) semantics of 'abbr' ("This attribute should be used to provide an 
abbreviated form of the cell's content") although in practice it might work 
just as well.

Anyone else have an opinion about this?

At 15:27 2004-10-28, Access Systems (Bob) wrote:
>On Thu, 28 Oct 2004, Marjolein Katsma wrote:
> > Please read the subject of my post. I'm asking about a *calendar*. I'm
> > asking for a *review*.
>
>in Linux using Minicom for web connection

This Minicom: http://alioth.debian.org/projects/minicom/ ?

>and reading the site in LYNX (text browser)  the little calendar at the top
>is not usable (is it intended to be useable??)

Errm, yes - it is intended to be usable (of course!).

That said, I realize that Lynx (I have the 2.8.3 Windows version here - 
which I do use to test with) does not support tables but simply shows their 
(linearized) contents. So whatever careful data table markup I come up with 
will fall flat on its face when read with Lynx anyway - not much I can do 
about that, I think. Although Sailesh's idea of using image links for 
"previous" and "next" month might help a little with making clear what the 
links are (no posts for this month, you'd have to navigate back to July or 
earlier to see any of those).

I'm not an expert Lynx user though - does / can it show title attributes 
for any element? ("Today" has a title attribute in the current month's 
calendar - can Lynx ever show that?) Can it show the title attributes on 
the previous / next month links?

I seem to remember Lynx is capable of showing at least some title 
attributes, but not being an expert user I keep forgetting how. How likely 
is it that a "regular" (but not expert) user of Lynx will ask for title 
attributes to be shown?

(Bob:)
>but the rest of the site including the dates
>which are listed vertically on the left side with links that work is quite
>usable, and in fact very easy (for me) to navigate.

This is good feedback, too, thanks. I did consciously provide several 
different ways of navigating the site (in place even before I left). It 
helps to know some of those work even if others (like the calendar) don't; 
this confirms what I've been able to deduce from visitor statistics (seeing 
some people actually trying out different types of navigation, and indeed 
finding all of them).

Now as long as there is an easy way to find out what's available on the 
site and explore it, I don't think it's too much of a problem if one 
particular navigation instrument (like the calendar) doesn't work with a 
particular user agent (one that doesn't support tables). Frankly, apart 
from Sailesh's idea of using image links (which would reveal the alt 
attributes in Lynx)  I really wouldn't know how to make that table more 
usable in a browser that doesn't support tables in the fist place - but I'm 
open to more suggestions, of course.

Have you (anyone?) ever used the Links browser? I understand it's a text 
browser that _does_ support tables but having Windows only I don't have 
access to it.

(Martin:)
>Some code reduction is possible, e.g. the heavy use of the class
>attribute is IMHO not necessary because a context is already there and
>context selectors could be used.

Most of the classes are used for visual styling (can't forget the blindless 
users of my site). I'll look into how I could reduce them somewhat, but 
it's important to have different (visual) styling for [ today | this month 
| next month | previous month | day with a link ] as well. (And the code 
generating all this is already pretty complicated - I'm not sure whether 
making it even more complicated just for getting rid of a few classes would 
actually be beneficial; it's a bit of a balancing act.)


All,

Thanks for the excellent feedback so far.

I'll try to tweak it a little more and see how that works out - but do keep 
the comments coming. Shoot any number of holes you like: I'm trying to make 
this site as *usable* (for all) as possible - and that's what accessibility 
is about, isn't it?

Cheers,


--
Marjolein Katsma
Travel Blog: http://iamback.com/blog/
Spam Reporting Addresses: http://banspam.javawoman.com/report3.html

Received on Thursday, 28 October 2004 18:13:39 UTC