E-mail List Archives
Number of posts in this thread: 19 (In chronological order)
From: smithj7
Date: Feb 14, 2007 8:50PM
Subject: Re: address tag
No previous message | Next message →
I use the address tag on my contact page. However, the default with my
websoftware is italics so I changed the style. For me it is just a quick
way to format on that page and try to get in the practice of using sematic
tagging.
I thought sematic tagging (e.g. cite, acryonm, abbr) was/is going to be more
important in the future. Is it true that sematic tagging is the wave of
the future?
----- Original Message -----
From: "Alastair Campbell" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Thursday, November 30, 2006 6:31 AM
Subject: Re: [WebAIM] address tag
>> Is the address tag good for accessibility?
>
> I would say it's fairly ambivalent at the moment with regards to
> accessibility. Not harmful, but not useful either.
>
> With regards to 'should I use it?', I would split this into three
> questions:
> 1. Is there anything useful about address tags for accessibility in the
> specs? (No.)
> 2. Do any current user agents do anything special with it? (Not that I
> know of.)
> 3. Is there any likely future use? (Unlikely.)
>
> For questions one and two: It is a tag with a confusing past, which has
> lead to it being used in different ways, and User-Agents not making any
> use of it.
>
> The address tag would seem appropriate for the type of uses that
> Microformats are being used for, such as being able to copy contact
> information from a web page straight into your addressbook.
>
> The reason I don't think it is likely to be much use in future is that:
> - Microformats don't use it for marking up addresses (see why here:
> http://tantek.com/presentations/2005/09/elements-of-xhtml/#slide5).
> - HTML 5 doesn't specify it as general contact information markup
> (http://www.whatwg.org/specs/web-apps/current-work/#the-address)
> - Neither does XHTML 2
> (http://www.w3.org/TR/xhtml2/mod-structural.html#sec_8.1.).
>
> Both HTML 5 & XHTML 2 define it as contact information for the document
> or section of a document.
>
> Since that isn't the general use that most people consider it for
> (marking up contact information), it is unlikely to be utilised by User
> Agents for contact information. The address element is likely to be
> trapped in a spiral of non-use.
>
> Personally, I'd go with microformats.
>
> For a quick fix for the italics, just apply this in the CSS:
> address {font-style: normal}
>
> Kind regards,
>
> -Alastair
>
> --
> Alastair Campbell | Director of User Experience
>
> Nomensa Email Disclaimer:
> http://www.nomensa.com/email-disclaimer.html
>
From: Tim Beadle
Date: Feb 15, 2007 2:10AM
Subject: Re: address tag
← Previous message | Next message →
On 15/02/07, = EMAIL ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = > wrote:
> I use the address tag on my contact page. However, the default with my
> websoftware is italics so I changed the style. For me it is just a quick
> way to format on that page and try to get in the practice of using sematic
> tagging.
<address> has been around for so long, but is not treated in any
special way. I'd say it's not especially relevant.
> I thought sematic tagging (e.g. cite, acryonm, abbr) was/is going to be more
> important in the future. Is it true that sematic tagging is the wave of
> the future?
It's good to use the elements that we have (including the ones you
mention) but they're quite limited in scope. If you want some semantic
goodness here and now, rather than when the capital 'S' and 'W'
Semantic Web arrives, have a look at Microformats:
http://microformats.org/ which basically uses existing HTML elements
and attributes to give content meaning.
I did a presentation on Tuesday about Microformats. The slides are here:
http://www.timandkathy.co.uk/presentations/microformats/
Best regards,
Tim
From: Peter Krantz
Date: Feb 15, 2007 3:10AM
Subject: Re: address tag
← Previous message | Next message →
On 2/15/07, Tim Beadle < = EMAIL ADDRESS REMOVED = > wrote:
> It's good to use the elements that we have (including the ones you
> mention) but they're quite limited in scope. If you want some semantic
> goodness here and now, rather than when the capital 'S' and 'W'
> Semantic Web arrives, have a look at Microformats:
> http://microformats.org/ which basically uses existing HTML elements
> and attributes to give content meaning.
>
Before committing development resources to implement microformats.org
microformats it is advisable to check out these posts:
http://friendlybit.com/html/current-issues-with-microformats/
http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml
I think the semantic web will have a lot of impact on accessibility in
the future. "Future" is of course what we all are waiting for so
microformat initiatives are welcome.
Currently, I have not seen anything that make web pages with
microformats more accessible than other webpages. If anyone knows of
software that makes use of microformats for accessibility purposes it
would be great to learn more.
Regards,
Peter Krantz
http:///www.standards-schmandards.com
http://www.peterkrantz.com
From: Tim Beadle
Date: Feb 15, 2007 3:40AM
Subject: Re: address tag
← Previous message | Next message →
On 15/02/07, Peter Krantz < = EMAIL ADDRESS REMOVED = > wrote:
> Before committing development resources to implement microformats.org
> microformats it is advisable to check out these posts:
>
> http://friendlybit.com/html/current-issues-with-microformats/
> http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml
I will have a look at those - thanks.
> I think the semantic web will have a lot of impact on accessibility in
> the future. "Future" is of course what we all are waiting for so
> microformat initiatives are welcome.
Indeed - some purists take issue with Microformats on the basis that
namespaced (X)HTML should be used instead. Microformats power smarter
web pages and applications *now*, not in some far-off future.
> Currently, I have not seen anything that make web pages with
> microformats more accessible than other webpages. If anyone knows of
> software that makes use of microformats for accessibility purposes it
> would be great to learn more.
Equally, adding Microformats to web sites will have no negative impact
on accessibility, while adding richness for everyone.
Best regards,
Tim
From: Patrick Lauke
Date: Feb 15, 2007 3:50AM
Subject: Re: address tag
← Previous message | Next message →
> Tim Beadle
> Equally, adding Microformats to web sites will have no negative impact
> on accessibility, while adding richness for everyone.
It's not that simple. Think, for instance, of the use of ABBR for the datetime design pattern
http://microformats.org/wiki/datetime-design-pattern
<abbr class="foo" title="YYYY-MM-DDTHH:MM:SS+ZZ:ZZ">Date Time</abbr>
Now think of a screen reader user that has "expand titles" or equivalent enabled (because, after all,
that's what we'd want them to do, no? that's the whole point why we use ABBR in the first place). What will they hear? An incomprehensible string of garbeage (the machine-readable ISO datetime)...
P
From: Tim Beadle
Date: Feb 15, 2007 4:00AM
Subject: Re: address tag
← Previous message | Next message →
On 15/02/07, Patrick Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> It's not that simple. Think, for instance, of the use of ABBR for the datetime design
> pattern
> http://microformats.org/wiki/datetime-design-pattern
>
> <abbr class="foo" title="YYYY-MM-DDTHH:MM:SS+ZZ:ZZ">Date Time</abbr>
>
> Now think of a screen reader user that has "expand titles" or equivalent enabled
> (because, after all, that's what we'd want them to do, no? that's the whole point why we
> use ABBR in the first place). What will they hear? An incomprehensible string of
> garbeage (the machine-readable ISO datetime)...
OK - fair point. There's a debate over this "abuse" of abbr at the
moment, apparently. I was a little dubious about it, I admit.
Tim
From: Jukka K. Korpela
Date: Feb 15, 2007 5:50AM
Subject: Re: address tag
← Previous message | Next message →
On Thu, 15 Feb 2007, Tim Beadle wrote:
> some purists take issue with Microformats on the basis that
> namespaced (X)HTML should be used instead.
That's irrelevant as such. What matters is whether markup is based on
well-designed, publicly reviewed and stable specifications _and_ whether
it becomes widely used. We have a long tradition of great confusion -
consider the rel="..." and rev="..." values for links. Everybody and his
brother invents new values and doesn't even bother defining what they are
really supposed to mean, as a matter of unambiguous semantics.
> Microformats power smarter
> web pages and applications *now*, not in some far-off future.
Such promises mean splitting the Web into incompatible microwebs. Luckily,
it is mostly just idle talk, hype, and pompous plans.
> Equally, adding Microformats to web sites will have no negative impact
> on accessibility, while adding richness for everyone.
Except when the particular microbabble happens to conflict with other
microbabble systems that are actually supported in some software, _or_
with processing of tags by their old semantics or by legacy rules. There
are so few tags and attributes in HTML that you'll end up with conflicting
with _something_ rather soon. Even <span title="...">...</span> isn't
harmless, since the title attribute _may_ be rendered to the user, perhaps
by special request, in a visible or audible way, even if a microformat fan
wanted to use it just for specific purposes to be handled by some fancy
"semantics aware" software.
Regarding the <address> element, it _would_ be quite useful for
accessibility purposes and otherwise, if it were used consistently.
Browsers could have a simple command "show document author's contact
info", for presenting the <address> element's content to the user.
This would be very useful on large complicated pages that might have such
information in some hard-to-find place.
However, the <address> element is more often than not used just as a
container for _any_ address. This has happened despite the fact that
several authoritative published specifications have defined it as an
element containing contact information on the author of the document
(or part of a document). This was partly a misunderstanding caused by a
poorly chosen element _name_ (<address> instead of <author>), but such
misunderstandings _will_ happen for microformats, since the names used in
them will be poorly chosen and poorly defined.
"Semantic web" is a great idea, but it won't even start getting realized
before the current "Semantic Web" fashion has been killed and buried
decently.
The _practical_ way to be semantic on the web at present, and in the near
future (and I mean years and decades), is to express your content verbally
in a clear, unambiguous, and easily understandable way. Words matter.
Search systems are being refined, but mostly so that they process _texts_
(and links between texts) in more elaborated ways.
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
From: smithj7
Date: Feb 15, 2007 4:00PM
Subject: Re: address tag
← Previous message | Next message →
Thanks for sharing this info Patrick. We have one section of our site that
is 100 percent used by persons who are either low vision users or speech
users. (Business Enterprise Program in Florida). I must keep this group of
customers happy.
----- Original Message -----
From: "Patrick Lauke" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Thursday, February 15, 2007 5:42 AM
Subject: Re: [WebAIM] address tag
>
>
>> Tim Beadle
>
>> Equally, adding Microformats to web sites will have no negative impact
>> on accessibility, while adding richness for everyone.
>
> It's not that simple. Think, for instance, of the use of ABBR for the
> datetime design pattern
>
> http://microformats.org/wiki/datetime-design-pattern
>
> <abbr class="foo" title="YYYY-MM-DDTHH:MM:SS+ZZ:ZZ">Date Time</abbr>
>
> Now think of a screen reader user that has "expand titles" or equivalent
> enabled (because, after all,
> that's what we'd want them to do, no? that's the whole point why we use
> ABBR in the first place). What will they hear? An incomprehensible string
> of garbeage (the machine-readable ISO datetime)...
>
> P
>
From: smithj7
Date: Feb 15, 2007 4:10PM
Subject: Re: address tag
← Previous message | Next message →
I definately would have been one of the persons raising my hands at your
presentation to indicate that I hadn't heard about microformats. I've
examined a couple of the links and will look at others during the next
couple of days.
----- Original Message -----
From: "Tim Beadle" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Thursday, February 15, 2007 3:59 AM
Subject: Re: [WebAIM] address tag
> On 15/02/07, = EMAIL ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = > wrote:
>> I use the address tag on my contact page. However, the default with my
>> websoftware is italics so I changed the style. For me it is just a quick
>> way to format on that page and try to get in the practice of using
>> sematic
>> tagging.
>
> <address> has been around for so long, but is not treated in any
> special way. I'd say it's not especially relevant.
>
>> I thought sematic tagging (e.g. cite, acryonm, abbr) was/is going to be
>> more
>> important in the future. Is it true that sematic tagging is the wave of
>> the future?
>
> It's good to use the elements that we have (including the ones you
> mention) but they're quite limited in scope. If you want some semantic
> goodness here and now, rather than when the capital 'S' and 'W'
> Semantic Web arrives, have a look at Microformats:
> http://microformats.org/ which basically uses existing HTML elements
> and attributes to give content meaning.
>
> I did a presentation on Tuesday about Microformats. The slides are here:
> http://www.timandkathy.co.uk/presentations/microformats/
>
> Best regards,
>
> Tim
>
From: Tim Beadle
Date: Feb 19, 2007 7:40AM
Subject: Re: address tag
← Previous message | Next message →
On 15/02/07, Jukka K. Korpela < = EMAIL ADDRESS REMOVED = > wrote:
> That's irrelevant as such. What matters is whether markup is based on
> well-designed, publicly reviewed and stable specifications _and_ whether
> it becomes widely used.
What's not public about the Microformats process, Jukka? You could
join in - edit the wiki, join the mailing list.
> We have a long tradition of great confusion -
> consider the rel="..." and rev="..." values for links. Everybody and his
> brother invents new values and doesn't even bother defining what they are
> really supposed to mean, as a matter of unambiguous semantics.
Except the values of class, rel, rev and title are the product of
design and consensus. There's lots of definition of "what they are
really supposed to mean" if you have a look on microformats.org.
> Such promises mean splitting the Web into incompatible microwebs. Luckily,
> it is mostly just idle talk, hype, and pompous plans.
Really? "Incompatible Microwebs"? Wherever do you get that idea from?
> Except when the particular microbabble happens to conflict with other
> microbabble systems that are actually supported in some software, _or_
> with processing of tags by their old semantics or by legacy rules.
Microbabble? Could we lay off the pejorative language, please?
> There
> are so few tags and attributes in HTML that you'll end up with conflicting
> with _something_ rather soon.
That's rather a negative outlook, isn't it? I admit I haven't been
using Microformats for that long, but I've seen no conflicts as yet.
> Even <span title="...">...</span> isn't
> harmless, since the title attribute _may_ be rendered to the user, perhaps
> by special request, in a visible or audible way
That's a fair point.
> even if a microformat fan
> wanted to use it just for specific purposes to be handled by some fancy
> "semantics aware" software.
"Fancy semantics aware software". Could we lay off the pejorative
language, please?
> "Semantic web" is a great idea, but it won't even start getting realized
> before the current "Semantic Web" fashion has been killed and buried
> decently.
Semantic Web (capital SW), as defined by the w3c, hasn't even got
going yet, mainly due to its insistence on purity and academic theory.
Microformats work precisely because they're simple and make use
(largely) of existing data within an HTML page.
See more at Mike Davies' blog:
"I nipped in with my stock standard accessibility question on what the
potential implications of microformats on web accessibility. Jeremy
had a clearly well-thought out answer to hand, which demonstrates that
accessibility has been considered, and not as an add-on. Essentially,
microformats create no new barriers for people with disabilities - in
the very rare case this may one day happen, the microformats are
ignorable. But there's a great wealth of richness on offer to
assistive technologies - in the microformat itself there are
identifiers and unambiguous data that can aid understanding and
comprehension. It is up to the assistive technologies vendor to take
advantage of these microformats in their devices."
http://www.isolani.co.uk/blog/semanticweb/WsgMicroformatsTalkLondon2006
> The _practical_ way to be semantic on the web at present, and in the near
> future (and I mean years and decades), is to express your content verbally
> in a clear, unambiguous, and easily understandable way. Words matter.
> Search systems are being refined, but mostly so that they process _texts_
> (and links between texts) in more elaborated ways.
Yes, words matter. In HTML as it stands, though, you still can't
define what content actually *is*, much of the time. Microformats let
you do that with many common types of data.
Perhaps you would like to actually find out a little more about
Microformats before declaring that they are of no practical use?
Tim
From: Jukka K. Korpela
Date: Feb 19, 2007 8:30AM
Subject: Re: address tag
← Previous message | Next message →
On Mon, 19 Feb 2007, Tim Beadle wrote:
> Microbabble? Could we lay off the pejorative language, please?
No, because ridiculing is one way of propagating the idea that
microformats are a wrong idea, similar to emperor's new clothes.
> Perhaps you would like to actually find out a little more about
> Microformats before declaring that they are of no practical use?
No, because it is the moral responsibility of proponents of the
microformats idea to demonstrate its practical usefulness, if they can. In
particular, if microformats are suggested as a means of improving
accessibility, the proof of their usefulness should demonstrate how they
actually help disabled users. So far, only _negative_ effects (such as
confusing people with nonsensical title attributes) have been described.
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
From: Tim Beadle
Date: Feb 19, 2007 12:20PM
Subject: Re: address tag
← Previous message | Next message →
On 19/02/07, Jukka K. Korpela < = EMAIL ADDRESS REMOVED = > wrote:
> No, because ridiculing is one way of propagating the idea that
> microformats are a wrong idea, similar to emperor's new clothes.
In your opinion. I offer an alternative view. I did a little digging,
and the accessibility of microformats is an issue that has not been
ignored.
Here is an example of an accessibility benefit of microformats, at
least in theory:
"*Accessibility Benefits*
For a disabled user, filling out a form can be a long and tedious job.
Depending on their input device, whether it be a keyboard,
voice-recognition, on-screen keyboard or whatever else, entering the
data manually can be quite time consuming. Also, their ability to spot
and correct errors may not be as fast as a non-disabled person, so the
less manual data entry required each time, the better.
Additionally, someone with a cognitive disability may have difficulty
understanding what some fields are asking for (especially if you've used
some obscure label text they're not used to) and thus make it hard to
complete. If the UA could understand the field, it could help explain
it or fill it out for them.
It would be so much quicker easier for them if their UA could either
pre-fill most of the form for them or just submit a vCard/hCard. For
the latter option, a user wouldn't even have to know what a vCard or
hCard was, their UA could recognise the accepted MIME type
(text/directory) and ask them to select a name from their address book,
which would then implicitly select (or generate) the right vCard."
-- http://microformats.org/discuss/mail/microformats-discuss/2006-September/005984.html
> No, because it is the moral responsibility of proponents of the
> microformats idea to demonstrate its practical usefulness, if they can.
I've tried to demonstrate some of that practical usefulness, but I'm
really only a beginner.
I think, however, that if you enter the argument negatively, calling
the (really rather excellent) work of the Microformats community
"microbabble", there's a fair chance that you will *never* see any
worth there because of your prejudiced viewpoint.
If you think that Microformats are broken, then get involved and help
fix them rather than standing on the sidelines.
> In
> particular, if microformats are suggested as a means of improving
> accessibility, the proof of their usefulness should demonstrate how they
> actually help disabled users. So far, only _negative_ effects (such as
> confusing people with nonsensical title attributes) have been described.
So see above for a positive example.
Best regards,
Tim
From: Patrick H. Lauke
Date: Feb 19, 2007 1:40PM
Subject: Re: address tag
← Previous message | Next message →
Tim Beadle wrote:
> Here is an example of an accessibility benefit of microformats, at
> least in theory:
> -- http://microformats.org/discuss/mail/microformats-discuss/2006-September/005984.html
That's a rather hypothetical benefit, though. It's a "if we had richer
semantics, and UAs actually understood them, there would be an
accessibility benefit" type argument. Microformats are one way to add
richer semantics, but the same argument can be made for XForms, XHTML
extended/mixed with other XML flavours, etc. Granted, with microformats,
the advantage would be that it's probably backwards compatible.
P
--
Patrick H. Lauke
From: Alastair Campbell
Date: Feb 20, 2007 2:40AM
Subject: Re: address tag
← Previous message | Next message →
> That's a rather hypothetical benefit, though. It's a "if we
> had richer semantics, and UAs actually understood them, there
> would be an accessibility benefit" type argument.
> Microformats are one way to add richer semantics, but the
> same argument can be made for XForms, XHTML extended/mixed
> with other XML flavours, etc. Granted, with microformats, the
> advantage would be that it's probably backwards compatible.
Microformats also take less effort to use, and because of this, they
have had good uptake even without decent user-agent side processing.
Because of the uptake, people are actually building user agents to use
them:
http://www.readwriteweb.com/archives/mozilla_does_microformats_firefox3.
php
(or: http://tinyurl.com/yeqlou)
Even now, if you add microformats to an events listing, you can then add
a link to 'subscribe' (e.g. at the bottom of
http://ukwindsurfing.com/events/).
(NB: I'll be changing the <abbr> to <span>, due to the title issue. I
don't think it's an issue now, but it could be.)
I've not looked into the capitalised 'Semantic Web' implementations, but
I'm guessing that from a developer point of view it's not that easy to
do the same? Personally, I would do whatever works best for the user. At
the moment Microformats is in the lead for usefulness.
Kind regards,
-Alastair
--
Alastair Campbell | Director of User Experience
Nomensa Email Disclaimer:
http://www.nomensa.com/email-disclaimer.html
From: Jukka K. Korpela
Date: Feb 20, 2007 3:00AM
Subject: Re: address tag
← Previous message | Next message →
On Tue, 20 Feb 2007, Alastair Campbell wrote:
> Because of the uptake, people are actually building user agents to use
> them:
Of course one can create user agents that utilize whatever fancy markup
might appear. You can do it even without any programming, just by writing
a user style sheet (especially if you use a browser that supports
generated content so that you can turn attribute values into visible
texts).
There's so much you can play. But this won't help accessibility. Rather,
it makes things more difficult, since it results in artificial and even
semantically wrong markup, thereby confusing people who use browsers that
utilize the defined meaning of markup (as defined in authoritative
specifications).
> Even now, if you add microformats to an events listing, you can then add
> a link to 'subscribe' (e.g. at the bottom of
> http://ukwindsurfing.com/events/).
I have no idea of what you mean by that, but the text at the bottom,
"Apple iCal and Thunderbird users can subscribe",
looks like discrimination, not accessibility.
> (NB: I'll be changing the <abbr> to <span>, due to the title issue. I
> don't think it's an issue now, but it could be.)
Of course it's an issue, and it will remain an issue even if you switch to
the meaningless (semantically empty) element name "span". The title
attribute still means "advisory title" by the book, but you are not using
it as a title but hidden container for data for some processing. The vast
majority of users will see the title attribute's value if they mouse over
the element.
If I see "20070711" when mousing over "Nov 17", I can guess what's going
on, but it really won't help me. To many people, it's just gibberish.
That is, it helps nobody but hurts many. (Changing "abbr" to "span"
does not change this, though it removes the disturbing and confusing
"dotted underline" on some browsers.)
> Personally, I would do whatever works best for the user.
Then you surely should not create obstacles to the vast majority, by
exploiting tricks that are supposed to work on some marginal applications
but are known to be processed quite differently (and more to the book) by
popular browsers.
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
From: Patrick Lauke
Date: Feb 20, 2007 3:20AM
Subject: Re: address tag
← Previous message | Next message →
> Jukka K. Korpela
> > Even now, if you add microformats to an events listing, you
> can then add
> > a link to 'subscribe' (e.g. at the bottom of
> > http://ukwindsurfing.com/events/).
>
> I have no idea of what you mean by that, but the text at the bottom,
> "Apple iCal and Thunderbird users can subscribe",
> looks like discrimination, not accessibility.
Generally, I agree with Jukka...but this was one of the points where I had to give out an audible groan here in the office.
Discrimination? Granted, the wording could be a bit more general (considering that Vista users can also subscribe, as far as I know, with their new calendar widget thing) a la "Get the schedule of events in iCal format" with a note explaining that iCal can be read by applications such as Apple iCal, Thunderbird, etc...but this is certainly no grounds for calling him a witch...aeh...saying that this is discrimination. Users without iCal capable calendaring software can still get all the information by...visiting the page, or using some web to email service to get notification when something has changed. Hardly discrimination. Or is offering RSS/Atom feeds also discriminating against users without an RSS reader? *rolls eyes*
P
From: Alastair Campbell
Date: Feb 20, 2007 3:40AM
Subject: Re: address tag
← Previous message | Next message →
Jukka Korpela wrote:
> I have no idea of what you mean by that, but the text at the
> bottom, "Apple iCal and Thunderbird users can subscribe",
> looks like discrimination, not accessibility.
You need something that understands the iCal format to subscribe, which
currently doesn't include Outlook. Given that Outlook doesn't support
subscribing to external calendars by any known standard, I would hardly
describe that as discrimination.
Is it not equivalent to complaining about not being able to use a web
site when you don't have a browser?
I believe Vista's calendar supports subscribing, being effectively an
iCal clone, so many people will be able to access this feature. (Not to
mention online calendars like Google also support it.)
For an organisation that exists to put on events, this is important
stuff.
> > (NB: I'll be changing the <abbr> to <span>, due to the
> title issue. I
> > don't think it's an issue now, but it could be.)
>
> Of course it's an issue
For who? I'm very interested to know of any user-agent that actually
reads out the title on an <abbr> element. Given IE's lack of support
for the element in general (which most UAs build on), I'm sceptical
there is one.
I realise they *should* provide an option to read out titles on an
<abbr>, but I don't see the use case for supporting <span>s.
> That is, it helps nobody but hurts many.
Oh come on, people with an app that supports subscription (a rapidly
increasing number) can subscribe to the calendar, receiving updates
without even visiting the site. On balance, I'd say it's more useful
than harmful.
With upcoming browsers (that are actually integrating this function
*now*), people will be able to drag n drop, or (if accessibility
concerns are understood) select any individual event on a page to add to
their calendar.
Patrick: Thanks, I haven't updated the wording since early 2006 when few
people will have come across this concept. I was hoping to hit some
key-words for people that do use those applications, but I will change
it.
Kind regards,
-Alastair
--
Alastair Campbell | Director of User Experience
Nomensa Email Disclaimer:
http://www.nomensa.com/email-disclaimer.html
From: Jukka K. Korpela
Date: Feb 20, 2007 3:50AM
Subject: Re: address tag
← Previous message | Next message →
On Tue, 20 Feb 2007, Patrick Lauke wrote:
> Or is offering RSS/Atom feeds also discriminating against users without
> an RSS reader? *rolls eyes*
Surely it is, if you do that by saying, at the bottom of a fairly
normal-looking web page,
"Zyphyxplytz and eFooX users can subscribe"
where "subscribe" is a link, and that's it.
Making some web content accessible _only_ in RSS format is surely
discriminating.
The situation is not comparable, though, since RSS has fairly stable
excuses for a specification, it is widely known and it is supported by the
modern versions of popular web browsers.
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
From: Jukka K. Korpela
Date: Feb 20, 2007 4:00AM
Subject: Re: address tag
← Previous message | No next message
On Tue, 20 Feb 2007, Alastair Campbell wrote:
> For who? I'm very interested to know of any user-agent that actually
> reads out the title on an <abbr> element. Given IE's lack of support
> for the element in general (which most UAs build on), I'm sceptical
> there is one.
Well, Mozilla, Opera - and IE 7. They display the title attribute value on
mouseover.
> I realise they *should* provide an option to read out titles on an
> <abbr>, but I don't see the use case for supporting <span>s.
Whether you see a case or not, <span title="..."> _does_ cause the title
attribute to be displayed - even on IE 6, so in that sense it makes things
worse _if_ you are abusing title (the attribute for an advisory title) for
microformat trickery.
>> That is, it helps nobody but hurts many.
>
> Oh come on, people with an app that supports subscription (a rapidly
> increasing number) can subscribe to the calendar, receiving updates
> without even visiting the site.
You're misreading the meaning of "it". It referred to what was discussed
just above it, the title attribute trick.
Regarding subscription to the calendar, I don't know anybody who would
want to do such things, but my point about it was the very cryptic nature
of the subscription link. The text certainly looked discriminatory, and it
did not even give a hint of what could be subscribed to (and hence what I
miss if I'm in the crowd that doesn't use the products mentioned).
Technically, if you wish to let people ask for information about updates
to a calendar, you could simply let them subscribe to a service that sends
announcements (with links to the current version of the calendar).
Certainly email announcements (properly written) are more accessible
than things that rely on specialized data formats and particular products
that process them. Even if you think that some xxx format is better
(at least for some people), you're doing things in quite a wrong order if
you first implement it (even if you don't actually fail to implement the
more robust approach).
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/