[whatwg] Dynamic content accessibility in HTML today

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

Re: [whatwg] Dynamic content accessibility in HTML today

27;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 JS widgets accessible,

Re: [whatwg] Dynamic content accessibility in HTML today

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

Re: [whatwg] Dynamic content accessibility in HTML today

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 navigab

Re: [whatwg] Dynamic content accessibility in HTML today

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

Re: [whatwg] Dynamic content accessibility in HTML today

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 yo

Re: [whatwg] Dynamic content accessibility in HTML today

m Ley wrote: 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 technolo

Re: [whatwg] Dynamic content accessibility in HTML today

f we put an alt text there then I find it likely that the screen reader will speak redundant, confusing information, at least in Firefox 1.5 I'll have to think about how we can avoid that. Thanks for bringing up the point. - Aaron Jim Ley wrote: On 14/08/06, Aaron Leventhal <[EMAIL

Re: [whatwg] Scoped tabindex proposal

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 attribu

Re: [whatwg] ARIA

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 functio

Re: [whatwg] ARIA

ARIA doesn't really overlap with HTML, because ARIA only reports what a JS developer is using elements for. So ARIA semantics should not affect behavior. Any code for dealing with ARIA markup should be strictly in the accessibility API support code (MSAA/IAccessible2/ATK/AT-SPI/UI Automatio

Re: [whatwg] ARIA

Jim Jewett wrote: I think the question is more about how the HTML elements themselves interact. For example, elements should probably be interpreted by default as because that is part of the semantics of tr. In some cases, the default mapping will also depend on other attributes. ( vs) Ide

Re: [whatwg] Are unfocusable elements focusable with tabIndex="-1".

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 f

Re: [whatwg] Are unfocusable elements focusable with tabIndex="-1".

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

Re: [whatwg] activedescendant in viewport (Re: scrollIntoView jarring?)

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 to

Re: [whatwg] ARIA

I don't know if you've seen the recent Accessible Rich Internet Applications draft? (There's also a primer at .) It describes a number of standard states that can be added to custom controls. Rather than potentially fi

[whatwg] Should enter be mapped to click?

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 like. What do people think? Should it

Re: [whatwg] Should enter be mapped to click?

3.4.1.7. Interactive content, paragraph 3: Thanks! Small typo: instead of being activating the element directly, Extra word "being" - Aaron

[whatwg] Ressurecting a11y thread [was Re: Video, Closed Captions, and Audio Description Tracks]

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 deciding

[whatwg] Early feedback on header association algorithm

1. On this part: "If there is a header cell in the table whose corresponding |th | element has an

Re: [whatwg] Early feedback on header association algorithm

n Nov 22, 2008, 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 <

Re: [whatwg] Early feedback on header association algorithm

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.ge

[whatwg] Question about allowed and descendants

http://dev.w3.org/html5/spec/Overview.html#the-ol-element > Categories:Flow content > Contexts in which this element may be used: Where flow content is expected. > Content mod

Re: [whatwg] Early feedback on header association algorithm

IMO it's not worth all the extra code and confusion to write a special table (but not inner table) ID getter. - Aaron On 12/6/2008 7:55 AM, Henri Sivonen wrote: On Dec 5, 2008, at 17:09, Aaron Leventhal wrote: How about node.getElementByIdInSubtree? It's not sufficient to get