+1 for Will's comments. First, Webkit needs strong accessibility foundation before moving onto advanced features like ARIA. While ARIA spec has reached its maturity, the user interaction model did not, and, I am afraid, we would not have answers for certain user interaction questions if asked right now. Regards, Vic
Willie Walker wrote: > Hi All: > > Just my 2 cents here: > > I would definitely object to WebKit being the de facto rendering engine > if it did not support accessibility. In addition, as WebKit > accessibility work is done, I recommend looking at the existing AT-SPI > implementation done in Gecko as a potential model for how the document > model can be represented via AT-SPI -- it was developed with real world > experience. Furthermore, I would also recommend collaborating with > assistive technologies along the way, making sure design decisions are > actually workable solutions. Finally, if it has not already been done, > I would suggest that the keyboard navigation model be nailed down -- > mouseless users need to be able to fully navigate web pages, cut/paste > content, etc. > > For ARIA, I agree that basic accessibility integration for web content > is a higher priority. This does not mean, however, that ARIA support > should not be included in the plans. My hope is that Maciej really > meant "we will look at basic accessibility integration first and ARIA > next" instead of "ARIA is an interesting toy and we won't support it." ;-) > > For yelp, I'm comforted that the team is targeting an accessible > solution for GNOME 2.24: > http://bugzilla.gnome.org/show_bug.cgi?id=499744. This will help give > our users much needed access to help and not require them to wait for > WebKit a11y to emerge. > > Will > > On Apr 1, 2008, at 6:32 PM, Eitan Isaacson wrote: > >> On Tue, 2008-04-01 at 16:37 -0400, David Bolter wrote: >>> Maciej Stachowiak wrote: >>>> 4) Accessibility. This is only implemented in the Mac port currently. >>>> We are moving the core accessibility code to be cross-platform, which >>>> should make it fairly straightforward to hook it up to ATK or other >>>> accessibility APIs. Sometimes ARIA is mentioned in the context of >>>> accessibility - this is an interesting technology for future web apps, >>>> but I believe basic accessibility integration for web content is a >>>> higher priority. >>>> >>> >>> This wording "Sometimes ARIA is mentioned in the context of >>> accessibility - this is an interesting technology for future web apps" >>> doesn't seem quite right to me. ARIA enabled browsers such as Firefox >>> provide access to ARIA enabled DHTML applications today. Opera and IE8 >>> are adding support today. Google is putting ARIA into its web >>> applications. >>> >> >> I agree with David. ARIA is becoming a major component in any accessible >> web application. It's not something in the distant future. It would be >> premature to crown webkit as the GNOME engine for all purposes until >> this is properly addressed. Nonetheless, for basic document viewing, >> like Yelp, Webkit could be a good solution, providing it has accessible >> structured document support. >> >> _______________________________________________ >> desktop-devel-list mailing list >> desktop-devel-list@gnome.org >> http://mail.gnome.org/mailman/listinfo/desktop-devel-list > _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
