Re: Calendar markup - review please?

Marjolein
here's what the calendar looks like in LYNX - interestingly enough if the <<
or >> links to previous next month is selected the page reloads and the next /
previous month's calendar is displayed. You'll note from the screen grab that
it appears on p15 of 25 in my LYNX browser (this will be different if you go
fullscreen with the TTY display); as yet i do not have an explanation for you
as to why there is a gap between Friday and Saturday's date columns; though
there may be margin or padding applied around the image or month name. I did a
quick test and changed the month name to <caption> (incl. the prev / next
links) and this still worked, and the gaps between cols dissapeared -
incidentally i would have used caption for the month (to comply with WCAG
checkpoint 5.5). (To those who will not be able to view the screengrab showing
calendar in LYNX - the calendar displays in matrix format - though there is a
gap between the Friday and Saturday's columns.)

i did not have any problems using this in LYNX; but i am fully sighted and do
not have to rely on audio to navigate through the pages - so i'd like to hear
how other users may have experienced this page. 

PS! I liked the site overall - you've obviously spent a lot of time in making
it as usable as possible. 

Regards
Harry
Ikhaya Internet Consulting
mobile : +44 (0) 794 034 3919
~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~
Good judgement comes from experience.
Experience, of course, is the result 
of poor judgement.
               - Geoff Tabin


---------- Original Message -----------
From: Marjolein Katsma <hgnje001@sneakemail.com>
To: w3c-wai-ig@w3.org
Sent: Thu, 28 Oct 2004 20:13:35 +0200
Subject: 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
------- End of Original Message -------