On Thu, 10 Aug 2006, Aaron Leventhal wrote:
I have a specific question: what about adding the role attribute to
whatwg specs?
Done, via reference to ARIA, and with a section describing restrictions
on allowed values.
--
Ian Hickson U+1047E)\._.,--,'``.
James Graham wrote:
OK, I think I hadn't appreciated just how vague the W3C document is. I
propose
we [standardize] the following:
A role attribute which may appear on (only non-semantic?) elements to
indicate
that that element is part of a DHTML widget and not marked-up prose. The
On Thu, 24 Aug 2006 19:36:53 +0200, James Graham [EMAIL PROTECTED] wrote:
Matthew Raymond wrote:
So [snip]ping lots of stuff that is kinda interesting but not in a very
relevant way.
The language of the |role| specification is actually unclear. The
intro indicates that |role| can be
Charles McCathieNevile wrote:
About right except there is a mechanism in the W3C work for adding new
values, which don't make it non-conforming. Given that people are pretty
inventive, I think that is quite valuable. YMMV
I don't see the point; if someone makes a value up and UAs don't
On Thu, 24 Aug 2006 20:16:14 +0200, James Graham [EMAIL PROTECTED] wrote:
Charles McCathieNevile wrote:
About right except there is a mechanism in the W3C work for adding new
values, which don't make it non-conforming. Given that people are
pretty inventive, I think that is quite valuable.
Matthew Raymond wrote:
Show me a spec that says that in a normative way. It is merely a best
practice. Class names, in general, are meaningless and meaningful class
names should not be part of the core specification.
The reason that semantic class names are best practice is because
class
On Mon, 14 Aug 2006 15:48:06 +0200, Anne van Kesteren
[EMAIL PROTECTED] wrote:
On Mon, 14 Aug 2006 06:36:40 -0700, James Graham [EMAIL PROTECTED] wrote:
But XBL works with ~0 assistive technologies and is presumably going to
be complex to implement properly. Whilst, in general, I agree that
James Graham said:
Of course, if you plan to put all the semantics of a document in the
class names, we could do away with many elements. Do you object to div
class=h1 as a replacement for h1?
I am reading this thread with interest but i have nothing serious to say.
However, i would ask
Matthew Raymond wrote:
The role attribute currently describes behavior, and is added so that
users with disabilities know what the behavior for a given element is,
according to well-known semantics. CSS is supposed to be for
presentational. In your scenarior, will there be any way to easily
James Graham wrote:
Matthew Raymond wrote:
The role attribute currently describes behavior, and is added so that
users with disabilities know what the behavior for a given element is,
according to well-known semantics. CSS is supposed to be for
presentational. In your scenarior, will
Aaron Leventhal wrote:
So you are saying this should be mapped to assistive technologies via
the CSS3 appearance property or via special values in the class attribute?
No, actually, I believe I made it clear in the last post that I
prefer predefined class names as the best way to address
James Graham wrote:
Matthew Raymond wrote:
[...] where a proper CSS presentation for the users primary media is
not available [...]
This is almost always the case on the real web.
Yeah, the web masters are so lazy that they can't be bothered to add
accessibility via CSS, but they'll be
So you are saying this should be mapped to assistive technologies via
the CSS3 appearance property or via special values in the class attribute?
The role attribute currently describes behavior, and is added so that
users with disabilities know what the behavior for a given element is,
On Mon, 14 Aug 2006 06:22:40 -0700, Aaron Leventhal [EMAIL PROTECTED]
wrote:
I like the role attribute because it's already usable in Mozilla, to
make accessible web applications. What's the advantage of using
class/appearance instead, if there is no browser already mapping this
Anne van Kesteren wrote:
On Mon, 14 Aug 2006 06:22:40 -0700, Aaron Leventhal
[EMAIL PROTECTED] wrote:
I like the role attribute because it's already usable in Mozilla, to
make accessible web applications. What's the advantage of using
class/appearance instead, if there is no browser already
Jim,
What browser/screen reader are you using?
You need at Firefox 1.5 or later and Window-Eyes 5.5 or later or JAWS 7
or later.
- Aaron
Jim Ley wrote:
On 13/08/06, Aaron Leventhal [EMAIL PROTECTED] wrote:
So we already have truly accessible DHTML widgets that are
key navigable and usable
Anne,
I said at the start of this thread that the best solution is to have
widgets that are already accessible. However, we don't have a standard
for that at the moment.
We agree that accessibility experts should not be needed in order to
make content accessible. It's not only big companies
- Original Message -
From: Anne van Kesteren [EMAIL PROTECTED]
To: James Graham [EMAIL PROTECTED]
Cc: WHATWG [EMAIL PROTECTED]
Sent: Monday, August 14, 2006 6:48 AM
Subject: Re: [whatwg] Dynamic content accessibility in HTML today
| On Mon, 14 Aug 2006 06:36:40 -0700, James Graham
[EMAIL PROTECTED]
Sent: Monday, August 14, 2006 6:48 AM
Subject: Re: [whatwg] Dynamic content accessibility in HTML today
| On Mon, 14 Aug 2006 06:36:40 -0700, James Graham [EMAIL PROTECTED] wrote:
| But XBL works with ~0 assistive technologies and is presumably going to
| be complex to implement
On 14/08/06, Aaron Leventhal [EMAIL PROTECTED] wrote:
What browser/screen reader are you using?
You need at Firefox 1.5 or later and Window-Eyes 5.5 or later or JAWS 7
or later.
I'm not using a screen reader, accessibility is about not requiring a
particular technology... Or did I miss a
Matthew Raymond wrote:
[...] where a proper CSS presentation for the users primary media is
not available [...]
This is almost always the case on the real web.
Yeah, the web masters are so lazy that they can't be bothered to add
accessibility via CSS, but they'll be working overtime
James Graham wrote:
Matthew Raymond wrote:
[...] where a proper CSS presentation for the users primary media is
not available [...]
This is almost always the case on the real web.
Yeah, the web masters are so lazy that they can't be bothered to add
accessibility via CSS, but they'll be
There are a lot more roles than what you listed, and they are all mapped
via desktop accessibility APIs such as MSAA and ATK to the assistive
technologies. So we already have truly accessible DHTML widgets that are
key navigable and usable with 3rd party tools such as screen readers.
If
On 13/08/06, Aaron Leventhal [EMAIL PROTECTED] wrote:
So we already have truly accessible DHTML widgets that are
key navigable and usable with 3rd party tools such as screen readers.
Could I ask where these are discussed? Because things like:
http://www.mozilla.org/access/dhtml/class/checkbox
James Graham wrote:
Matthew Raymond wrote:
What Firefox is doing for DHTML accessibility has a very narrow use
case. It applies to DHTML widgets, that are not bound to fallback markup
using XBL [...]
Without commenting (yet!) on the rest of this thread, I should just note
that any
The XBL code in the Safari tree is dead. It's not compiled, and it
was based on XBL1 (Mozilla's XBL) anyway.
dave
On Aug 12, 2006, at 7:56 PM, Matthew Raymond wrote:
James Graham wrote:
Matthew Raymond wrote:
What Firefox is doing for DHTML accessibility has a very
narrow use
case.
Firefox has support for making dynamic web applications with custom JS
widgets accessible, via support for xhtml:role and aaa: properties. If
anyone would be interested in taking a look, I would welcome feedback.
In Firefox 1.5 the role attribute had to use the xhtml2 namespace.
However,
27 matches
Mail list logo
