Re: WebKit and GNOME

[David Bolter]

Hi Maciej,

Thanks very much for providing this information. I have a brief comment
about your accessibility section below:

Maciej Stachowiak wrote:
> Hello GNOMErs,
>
> Some of you may remember me from back in my GNOME development days.
> These days I work on WebKit, an open source Web content engine. I've
> heard that WebKit is of interest to the GNOME/Gtk community, and I
> have followed the Gtk+ port in WebKit trunk closely. Since WebKit/Gtk+
> is now under consideration as an external dependency for GNOME, I
> thought I'd share some information about WebKit from my perspective.
>
> I think the GNOME project has to decide for itself, so I'm going to
> try to avoid excessive marketing, but obviously it is impossible for
> me to completely avoid bias.
>
> One thing to consider is whether WebKit's goals are aligned with
> GNOME's requirements for a Web content engine. I don't think I can
> describe them better than our statement of project goals: <http://webkit.org/projects/goals.html
> >.
>
> I think WebKit has a couple of strengths from the perspective of
> desktop integration. The WebKit project sees itself as a technology
> provider, not an end-user product. For this reason, we put a high
> priority on making the engine usable for a wide variety of
> applications, and on enabling tight integration with different
> environments. As a result of this focus we have:
>
> 1) Easy to use platform-native APIs on each target platform. The Mac
> OS X port's Objective-C/Cocoa API has been widely praised, and the Qt
> and Gtk+ ports provide their own native-feeling APIs. Here is a
> partial (and somewhat out of date) list of the many applications using
> WebKit: <http://trac.webkit.org/projects/webkit/wiki/Applications%20using%20WebKit
> >.
>
> 2) Extensive use of platform-native APIs and services. Our porting
> layer is designed to build on top of a capable underlying operating
> environment, and to make use of its services. This reduces code
> footprint (no need to duplicate code that is already in platform
> libraries) and enables tight integration.
>
> More generally, we let platform owners decide on the strategic
> direction for their port's API and platform integration. Apple owns
> the Mac port and generally takes the lead in deciding what the API
> looks like on Mac OS X, but the Qt and Gtk+ ports are designed by
> TrollTech and by Gtk+-focused WebKit developers respectively.
>
> Besides these strengths from the point of view of integration, I think
> WebKit has a number of other strengths:
>
> 1) Web standards compliance. WebKit has a high degree of Web standards
> compliance. We not only get the basics right but are often the first
> to pass standards compliance torture tests like Acid2, and recently
> Acid3: <http://webkit.org/blog/173/webkit-achieves-acid3-100100-in-public-build/
> >. We have also been pushing ahead with early support for forthcoming
> new standards like CSS3 and HTML5.
>
> 2) Performance. Our performance rocks. You can find lots of benchmarks
> out there for speed and memory and WebKit isn't the winner of every
> single one, but you'll find that we're often first and rarely last.
> With memory use the story is somewhat more complicated. Our memory use
> depends partly on the platform integration layer (images in the memory
> cache are a large component) and partly on low-level bits of the
> custom allocator. It is much better on Mac OS X than Windows, because
> our custom allocator supports returning memory to the system. I
> believe this code will work on other Unix-like platforms (such as
> Linux), but I haven't personally tested. We're hoping to make it work
> on Windows as well. In all fairness I have to say that other engines
> such as Gecko (from Mozilla) and Presto (from Opera) are also quite
> good in many performance metrics, especially with recent improvements.
> In addition to browser performance, we've also done optimization
> specifically for mail and instant messaging clients, and RSS readers.
> One result of this is a scalable memory cache, so that WebKit in IM
> clients uses much less memory than in a primary web browser.
>
> 3) Web compatibility. Web standards are nice and all, but, at least in
> the browser, the bottom line for users is whether they can use the
> sites they want to. Realistically, a lot of this depends on market
> share. Internet Explorer and Firefox often have an edge simply because
> Web developers are more likely to test in those browsers first.
> However, increasingly Web developers are testing in Safari early, or
> even developing in Safari first. Safari's growing market share, the
> iPhone, and the popularity of WebKit as a browser engine on mobile
> platforms are all giving major web developers more incentive to test
> with us. In addition, we have done huge amounts of compatibility work.
> In the span from Safari 2 to Safari 3, we fixed thousands of web
> compatibility bugs and in particular made huge strides with rich text
> editing (a longstanding problem area).
>
> 4) Hackability. I think our greatest strength is the hackability of
> our code. Although a Web content engine is intrinsically pretty
> complicated, we put a huge focus on simplicity and understandability,
> both in initial development and constant aggressive code cleanup.
> This, combined with our extensive regression test suite, allows us to
> make progress very quickly, and makes it easy to customize WebKit for
> particular applications as needed.
>
>
> To be fair, I think there are also weaknesses that need to be
> addressed in WebKit in general, or in the Gtk+ port in particular:
>
> 1) BuildBot and regression test integration. The WebKit/Gtk+ port is
> not yet set up to run our regression test suite. We think having this
> set up is important to ensure that the rapid pace of WebKit
> development doesn't constantly break the Gtk+ port, and that the Gtk+-
> specific parts are working as expected. This shouldn't be too much
> work to set up, as there are Mac, Windows and Qt versions of the
> regression test tool already.
>
> 2) API completeness. Some advanced parts, like a GObject API to the
> DOM, remain to be done.
>
> 3) Linux/Gtk-specific performance tuning. Most WebKit performance work
> has been done on Mac or Windows, probably running speed tests,
> profilers and memory tools on the Gtk port would find platform-
> specific areas that can be improved.
>
> 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 do however agree that addressing the cross platform accessibility
strategy in WebKit should come first and wish WebKit the best in this
endeavor.

cheers,
David

>
> I'm also happy to answer technical questions about WebKit, or what our
> development process is like. I will defer to the WebKit/Gtk+ crew for
> Gtk-port-specific questions, however.
>
>
> Regards,
> Maciej
>
>
> _______________________________________________
> desktop-devel-list mailing list
> desktop-d...@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>

[Eitan Isaacson]

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.

[Willie Walker]

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

[David Bolter]

Hi Maciej,

Maciej Stachowiak wrote:
>
> On Apr 1, 2008, at 3:44 PM, Maciej Stachowiak wrote:

>
>>
>> On Apr 1, 2008, at 12:13 PM, David Bolter wrote:
>>
>>> Hi Maciej,
>>>
>>> Thanks very much for providing this information. I have a brief
>>> comment about your accessibility section below:
>>>
>>>

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

>> So far as I know, there isn't any major web app yet that is already
>> using ARIA. I would appreciate correction on this front if I have
>> missed anything.
>
> By the way, just to be clear, I do not mean to imply that ARIA is not
> an important technology, or that it is "far future". Just that, in my
> estimation, basic accessibility integration is much more beneficial to
> users, in the short to medium term. (ARIA will probably be quite
> feasible to implement in a cross-platform way once the basic
> accessibility code is cross-platform.)

Yes my original reply got trimmed a bit so I'll paste in the missing
part again: "I do however agree that addressing the cross platform

accessibility strategy in WebKit should come first and wish WebKit the
best in this endeavor."

Good luck, and I really hope the WebKit accessibility person(s) can take
advantage of the help the GNOME and Mozilla communities can provide in
making sure that cross platform WebKit accessibility can fly.

cheers,
David
>
> It is up to the GNOME project of course whether you will attach any
> specific feature requirements to accepting WebKit as an external
> dependency.
>
> Regards,
> Maciej
>

[David Bolter]

Hi Maciej,

Maciej Stachowiak wrote:
> On Apr 1, 2008, at 12:13 PM, David Bolter wrote:
>
>
>> Hi Maciej,
>>
>> Thanks very much for providing this information. I have a brief
>> comment about your accessibility section below:
>>
>>
>> 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.
>>
>
> So far as I know, there isn't any major web app yet that is already
> using ARIA. I would appreciate correction on this front if I have
> missed anything.
>

Sure. I'm not sure what classifies as a major web app, but how about
Google reader?
http://www.google.com/reader/view/?ui=axs

cheers,
David

[Steve Lee]

Do I remember plans to have a directory of accessible web apps?
Did it ever happen?

Steve

--
Steve Lee
--
Open Source Assistive Technology Software
web: fullmeasure.co.uk
blog: eduspaces.net/stevelee/weblog

[David Bolter]

Maciej Stachowiak wrote:

> On Apr 2, 2008, at 8:14 AM, David Bolter wrote:
>
>
>> Hi Maciej,
>>
>> Maciej Stachowiak wrote:
>>
>>> On Apr 1, 2008, at 12:13 PM, David Bolter wrote:
>>>
>>>
>>>
>>>> Hi Maciej,
>>>>
>>>> Thanks very much for providing this information. I have a brief
>>>> comment about your accessibility section below:
>>>>
>>>>
>>>> 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.
>>>>
>>>>
>>> So far as I know, there isn't any major web app yet that is
>>> already using ARIA. I would appreciate correction on this front if
>>> I have missed anything.
>>>
>>>
>> Sure. I'm not sure what classifies as a major web app, but how about

>> google reader?
>> http://www.google.com/reader/view/?ui=axs
>>
>
> I did find Google Reader in the FAQ just now, but it took me a while
> to find the ARIA-enhanced version, since the main version does not
> have ARIA markup and just has an invisible link. I'm looking right now
> for actual signs of ARIA markup in the axs version using the live DOM
> view of the Safari web inspector, I can't seem to find any elements
> with aria-* attributes on them. Can anyone help me figure out where to
> look?
>

You can see aria- markup in the html view of Firebug on FF. Here's a
screenshot:
http://david-bolters-computer.local/workspace/exploratory/google-reader-aria.png

(I squished the window to waste less bits)

In this example the body has the aria-activedescendent specified. I
imagine Google might be injecting the aria markup (via AxsJax) so I'm no
sure what to expect on Safari. I tried using Drosera on Webkit but
didn't see the markup there either. Maybe Charles or T.V. will chime in :)

cheers,
David

> (In-the-wild use of ARIA is important for us for prioritization, and
> eventually testing, which is why I'd like to know about it.)
>
> Cheers,
> Maciej

[David Bolter]

Hi Maciej,

Reposting with the correct URL...

http://david.atrc.utoronto.ca/exploratory/google-reader-aria.png

[Victor Tsaran]

+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

[Aaron Leventhal]

I agree about the strong a11y foundation being the necessary start, but
WebKit might save work down the road by planning for ARIA now.

Victor, I don't understand your comment about the UI interaction model.
I think that affects things on the AT end but not so much how ARIA is
exposed via ATK/AT-SPI?

- Aaron

[Aaron Leventhal]

[T.V Raman]

We inject the ARIA markup and other enhancements as needed from
the core Reader product.

Most of these attributes are added at runtime, not in static
markup, since Reader is a very dynamic Web Application -- it's
*not* a document.

Also, in general, we will only emit ARIA markup to clients that
are capable of using the enhancements; it would be silly to ship
extra bytes to a browser that is going to throw it away.

David Bolter writes:
> Maciej Stachowiak wrote:
> > On Apr 2, 2008, at 8:14 AM, David Bolter wrote:
> >
> >
> >> Hi Maciej,
> >>
> >> Maciej Stachowiak wrote:
> >>
> >>> On Apr 1, 2008, at 12:13 PM, David Bolter wrote:
> >>>
> >>>
> >>>
> >>>> Hi Maciej,
> >>>>
> >>>> Thanks very much for providing this information. I have a brief
> >>>> comment about your accessibility section below:
> >>>>
> >>>>

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

> >>> So far as I know, there isn't any major web app yet that is
> >>> already using ARIA. I would appreciate correction on this front if
> >>> I have missed anything.
> >>>
> >>>
> >> Sure. I'm not sure what classifies as a major web app, but how about
> >> google reader?
> >> http://www.google.com/reader/view/?ui=axs
> >>
> >
> > I did find Google Reader in the FAQ just now, but it took me a while
> > to find the ARIA-enhanced version, since the main version does not
> > have ARIA markup and just has an invisible link. I'm looking right now
> > for actual signs of ARIA markup in the axs version using the live DOM
> > view of the Safari web inspector, I can't seem to find any elements
> > with aria-* attributes on them. Can anyone help me figure out where to
> > look?
> >
>
> You can see aria- markup in the html view of Firebug on FF. Here's a
> screenshot:

> http://david-bolters-computer.local/workspace/exploratory/google-reader-aria.png

>
> (I squished the window to waste less bits)
>
> In this example the body has the aria-activedescendent specified. I
> imagine Google might be injecting the aria markup (via AxsJax) so I'm no
> sure what to expect on Safari. I tried using Drosera on Webkit but
> didn't see the markup there either. Maybe Charles or T.V. will chime in :)
>
> cheers,
> David
>
>
>
> > (In-the-wild use of ARIA is important for us for prioritization, and
> > eventually testing, which is why I'd like to know about it.)
> >
> > Cheers,
> > Maciej
> >

> > _______________________________________________
> > desktop-devel-list mailing list
> > desktop-d...@gnome.org
> > http://mail.gnome.org/mailman/listinfo/desktop-devel-list
> >
>

> _______________________________________________
> dev-accessibility mailing list
> dev-acce...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-accessibility

--
Best Regards,
--raman

Title: Research Scientist
Email: ra...@google.com
WWW: http://emacspeak.sf.net/raman/
Google: tv+raman
GTalk: ra...@google.com, tv.ra...@gmail.com
PGP: http://emacspeak.sf.net/raman/raman-almaden.asc

[Joseph Scheuhammer]

1. Using DHTML to create desktop UI's is here, today, now. It has
become very popular. Nonetheless, it is inaccessible because the
semantics of the markup is either wrong or neutral with respect to the
UI it is encoding. A specific example is where a <div> element can be a
menu, a menu item, a combobox, a page tab, a slider, or any number of
other UI widgets. Knowing that it's a <div> doesn't tell you much.

2. ARIA is the W3C draft standard that deals with the semantics of
DHTML-as-UI. There are other similar efforts (e.g., microformats), but
they haven't the same traction.

3. FireFox, Opera, and the dojo JavaScript toolkit already implement
ARIA. jQuery, IE8, and Adobe are in the process of doing so.

> So far as I know, there isn't any major web app yet that is already
> > using ARIA. I would appreciate correction on this front if I have
> > missed anything.
> >
>
> Sure. I'm not sure what classifies as a major web app, but how about

> Google reader?
> http://www.google.com/reader/view/?ui=axs
>

On the assumption that there is a major web app that is using DHTML for
its UI, the issue is not whether it is already using ARIA; the issue is
how can that webapp be made accessible if it isn't using ARIA?

--
;;;;joseph

'This is not war -- this is pest control!'
- "Doomsday", Dalek Leader -

[James Craig]

Joseph Scheuhammer wrote:

> 2. ARIA is the W3C draft standard that deals with the semantics of
> DHTML-as-UI. There are other similar efforts (e.g., microformats),
> but
> they haven't the same traction.

Just to be clear, I'm a fan of ARIA, but this statement is false. The
Microformats effort is trying to solve a completely different problem,
and it arguably has a lot more traction than ARIA. A better example of
a similar effort would be, WebAPI, the other W3C Working Group that is
doing almost exactly the same thing, except without the focus on
accessibility.

http://www.w3.org/2006/webapi/

A quick search of that group's wiki yields no results for ARIA,
accessible, or accessibility. Granted, that group seems to be more
focused on client-server communication protocols than front-end UI
elements, but from an outside perspective, it appears that no cross-
group communication is happening between PF and WebAPI. Is this the
case?

http://www.w3.org/2008/webapps/wiki/Special:Search?search=ARIA

James

[David Bolter]

James Craig wrote:
> Joseph Scheuhammer wrote:
>
>
>> 2. ARIA is the W3C draft standard that deals with the semantics of
>> DHTML-as-UI. There are other similar efforts (e.g., microformats),
>> but
>> they haven't the same traction.
>>
>
> Just to be clear, I'm a fan of ARIA, but this statement is false. The
> Microformats effort is trying to solve a completely different problem,
> and it arguably has a lot more traction than ARIA.

I can't speak for him, but I think Joseph was referring to the idea some
folks might have had about using microformats to capture the kinds of
semantics ARIA is addressing. This particular usage of microformats
hasn't the same traction (any traction?) as ARIA.

> A better example of
> a similar effort would be, WebAPI, the other W3C Working Group that is
> doing almost exactly the same thing, except without the focus on
> accessibility.
>
> http://www.w3.org/2006/webapi/
>
> A quick search of that group's wiki yields no results for ARIA,
> accessible, or accessibility. Granted, that group seems to be more
> focused on client-server communication protocols than front-end UI
> elements, but from an outside perspective, it appears that no cross-
> group communication is happening between PF and WebAPI. Is this the
> case?
>
> http://www.w3.org/2008/webapps/wiki/Special:Search?search=ARIA
>
>

Very interesting. I also wonder what the relationship between WebAPI and
the PF is...

cheers,
David

[Joseph Scheuhammer]

James,

In a nutshell, the issue I was trying to get at was that DHTML needs its
semantics exposed and published. If not by ARIA, then how?

> The Microformats effort is trying to solve a completely different

> problem ... it arguably has a lot more traction than ARIA.

Traction is relative. Microformats could be as solid a technology as
anyone could want, but if, as you say, it doesn't help with the
semantics of a JavaScript based UI, then it has no use at all in that
regard. But, that actually strengthens the case for ARIA, since you've
eliminated an alternative.

You do suggest another approach, or perhaps another effort that would
converge with ARIA on a solution, that being WebAPI. I know very little
about it and so am in no position to comment. Time to do some
research. However, how does it compare and contrast with ARIA? I find
it worrisome that your search did not yield "....any results for ...
accessible, or accessibility". That doesn't sound promising: however, I
won't prejudge the situation.

> it appears that no cross-
> group communication is happening between PF and WebAPI. Is this the
> case?

I don't know (yet) since I am in the process of joining the PFWG. Are
they any PFWG or WebAPI members on this list who can comment?

[Charles McCathieNevile]

On Fri, 04 Apr 2008 20:34:28 +0200, David Bolter
<david....@utoronto.ca> wrote:

> James Craig wrote:
>> Joseph Scheuhammer wrote:

...

>> A better example of
>> a similar effort would be, WebAPI, the other W3C Working Group that is
>> doing almost exactly the same thing, except without the focus on
>> accessibility.
>>
>> http://www.w3.org/2006/webapi/

No, we do different stuff. The WebAPI group works on APIs - generally
things with no particular accessibility focus at all (although
occasionally thatis not the case, such as in dealing with UI events in DOM
3).

>> A quick search of that group's wiki yields no results for ARIA,
>> accessible, or accessibility. Granted, that group seems to be more
>> focused on client-server communication protocols than front-end UI

>> elements, but from an outside perspective, it appears that no cross-

>> group communication is happening between PF and WebAPI. Is this the
>> case?

...

> Very interesting. I also wonder what the relationship between WebAPI and
> the PF is...

The chair (me) is a member of (and ex staff contact for) PF although not
hugely active there, and there is ongoing communication, typically via the
HTML Coordination Group (designed to facilitate coordination between
groups) or directly, depending on how detailed it needs to be. There are
also probably other members in common, and there are certainly other
people who are at least lurking in both groups.

In addition some members (like Opera) have active people in both groups,
who coordinate as part of their day jobs.

This is the normal model for W3C groups, actually.

cheers

Chaals

--
Charles McCathieNevile Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com