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,
accessible in a web page today. I don't think it's a narrow use case.
Look at the huge numbers of websites that are trying to become more like
desktop applications.
- Aaron
Matthew Raymond wrote:
Aaron Leventhal wrote:
Firefox has support for making dynamic web applications with custom
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,
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
I'm not at all arguing against having the better, more full-featured
elements available in whatwg. I'm not saying that roles should subsume
anything happening here.
I'm suggesting something else, more like:
1) Use the role and state documents that will be public drafts soon, to
find gaps in
tabindex=-1 doesn't just remove items from the tab order. It also
makes items focusable via mouse click or script, which is important when
designing custom container widgets like spreadsheets, etc. via
Javascript. In fact any negative value does it.
Don't try to overload the tabindex
James Graham wrote:
Dave Hodder wrote:
The current HTML 5 draft doesn't mention ARIA anywhere. Perhaps it
should clarify the relationship (or non-relationship as it is at
present), even if it's only a brief mention in section 1.1.
Unfortunately a brief mention is insufficient as aria
Jim Jewett wrote:
I think the question is more about how the HTML elements themselves
interact.
For example,tr elements should probably be interpreted by default
astr aria-role=row because that is part of the semantics of tr.
In some cases, the default mapping will also depend on other
As I mentioned in the WebKit bug report just now
(https://bugs.webkit.org/show_bug.cgi?id=7138):
The WhatWG spec appears to be wrong, in that it says:
A negative integer specifies that the element should be removed from the tab
order. If the element does normally take focus, it may still be
So how do I know if this has been registered as a pending issue that
will be fixed in the spec?
I checked with Opera and they also do tabindex=-1 makes anything
focusable.
So the spec is out of line with implementations.
- Aaron
I think if there is an attribute like this which also scrolls for you,
then it should be called activedescendant, not aria-activedescendant. I
don't see a problem if HTML 5 wants the attribute without aria- to drive
browser behavior. In that case perhaps it should style the active
descendant
Now that tabindex can be used on any element to make it focusable, it makes
sense that it should be possible to trigger a click on those elements with the
keyboard.
Opera maps Enter to click. As far as I know, other browsers only do that for a few
elements likea.
What do people think? Should
3.4.1.7. Interactive content, paragraph 3:
Thanks! Small typo:
instead of being activating the element directly,
Extra word being
- Aaron
Has anyone put any further thought on what to do about captions for Ogg?
We've started to throw some thoughts together here:
https://wiki.mozilla.org/Accessibility/Captioning_Work_Plan
We could use some help from individuals who understand the area of video
and captions. The problem of
1. On this part:
If there is a header cell in the table
http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#concept-table
whose corresponding |th
http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#the-th-element|
element has an ID
, at 15:50, Henri Sivonen wrote:
On Oct 29, 2008, at 19:43, Aaron Leventhal wrote:
1. On this part:
If there is a header cell in the table
http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#concept-table
whose corresponding |th
http://www.whatwg.org/specs/web
How about node.getElementByIdInSubtree?
On 12/2/2008 4:07 PM, timeless wrote:
On Tue, Dec 2, 2008 at 10:39 AM, Aaron Leventhal[EMAIL PROTECTED] wrote:
Maybe there is a deeper problem if copy paste doesn't work right because
of IDs?
Or maybe there should be a node.getDescendantById
http://dev.w3.org/html5/spec/Overview.html#the-ol-element
Categories:Flow content
http://dev.w3.org/html5/spec/Overview.html#flow-content-0
Contexts in which this element may be used: Where flow content
http://dev.w3.org/html5/spec/Overview.html#flow-content-0 is expected.
Content model:
19 matches
Mail list logo
