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. 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.
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 support
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 u
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 used to "describe the semantic
meaning" of elements, while Section 3 says the fo
James Graham wrote:
> 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 name
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
clas
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 t
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 class="h1"> as a replacement for ?
I am reading this thread with interest but i have nothing serious to say.
However, i would ask what
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 scenar
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 kn
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
I'll think about it what you say about the checkbox. Honestly it hasn't
come up before. You're right in that if images are turned off then this
example is no longer accessible to sighted users.
While screen readers aren't the only important thing, they are
important. If we put an alt text the
On 14/08/06, Aaron Leventhal <[EMAIL PROTECTED]> wrote:
I hadn't considered putting an alt text on it, because the image's
function is described by the role itself.
It's got nothing to do with it's function, you've got an image in the
page, to be accessible a user has to be able to find out wha
On Mon, 14 Aug 2006 11:09:53 -0700, Aaron Leventhal <[EMAIL PROTECTED]>
wrote:
I'm suggesting something else, more like:
1) Use the role and state documents that will be public drafts soon, to
find gaps in your set of elements. If those semantics aren't available
in your set of fully functio
Jim,
I hadn't considered putting an alt text on it, because the image's
function is described by the role itself.
Does the image for a checkbox using a standard html need an alt text?
In any case, more effort on better examples is being put into Dojo,
where the code will actually be used. Thi
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 me
gt;
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]> wrote
- 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 tod
Anne van Kesteren wrote:
So a while ago I posted
http://annevankesteren.nl/2006/06/accessibility-ideas some of my
thoughts regarding role=""... Basically, I don't really see authors
taking extra steps to make things accessible.
The same argument applies, presumably, to the alt attribute. And
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
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
having elements used in the correct way to provide semantic information
is de
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 usabl
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 m
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
informati
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,
accord
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,
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/checkbo
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 you're
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 wo
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 puttin
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. I
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
Matthew Raymond wrote:
Aaron Leventhal wrote:
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.
What Firefox is doing for DHTML
Aaron Leventhal wrote:
> 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.
What Firefox is doing for DHTML accessibility has a
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, Firef
37 matches
Mail list logo