GNOME.org
 

Re: WebKitGTK+ as an external dependency

Hi All:
The first goal I believe we are targeting for WebKit accessibility is that it is on par with Gecko, modulo ARIA support. Without that, I'm not sure why a user with a disability would want to see a migration away from Gecko to WebKit.
I think the work Joanie and Xan have been doing is getting us towards that goal, and both are doing a great job identifying the remaining work needed to achieve that goal.
Having said that, it is my understanding that apps such as yelp are working on supporting both Gecko and WebKit. If this is the case, would the choice of rendering engine be done at run time or compile time? 

Will

Joanmarie Diggs wrote:

Hi Guys.


First of all, sorry for the late reply, I was away on Paris last week.


Must be rough. ;-) ;-) ;-)


Certainly having more people hacking on WebKitGTK+ wouldn't hurt us,
but since this tends to be true for most free software projects I
don't think this will be shocking news for anyone.


Agreed.


About the question of whether we are on track to have stuff working for 2.28:

My understanding from conversations with Joannie was that having a
complete fix for https://bugs.webkit.org/show_bug.cgi?id=25415 would
give us a reasonable basic experience with Orca, 

For accessing basic text -- not documents of even slight complexity or
forms. Sorry for any confusion I caused on that front! :-(

To be clear: Without your work on the above bug -- combined with the
work done in the area of caret navigation -- there would be nothing we
could do in Orca, and users who are blind would be completely, utterly
unable to access any WebKit content whatsoever. That get_text_at_offset
largely works as expected is a huge, awesome milestone (thanks!!). I am
now able to work on Orca's script for Epiphany. And for super-basic text
documents things do work (modulo the remaining issues around line
boundaries and around caret navigation). For anything beyond the
simplest of documents, however, I'm afraid we need fixes for those other
bugs I'd filed.


and hopefully give us
confindence that with a couple more months of bug fixing we could make
it for 2.28. 

And maybe we still can. But I don't feel comfortable stating that things
will all be good for 2.28 without knowing what will be fixed by then and
what issues will remain.


It seems from the last mails that this might not be the
case, so before answering the question I think I should ask: do we
have clear cut goal for 2.28?


That's an excellent question. What is the definition of "good enough"?
That the majority of documents will not be accessible to users who are
blind concerns me. But I'm just one person. If the rest of the community
agrees that "good enough" means basic text documents, I'll abide by that
and continue to do what I can in Orca.


Clearly fixing all a11y bugs in the
tracker won't happen (anytime soon probably), since we'll find new
issues as we fix the existing bugs, because we are able to use more
functionality. My understanding is that we all realize there will be
a11y regressions compared to Gecko in the near future, and that at
least for 2.28 all we can aim for is to give a substantial bump to our
support (which I think we are doing), enough to get the tools in a
working state, so that the Release Team feels confident in having
WebKitGTK+ as as external dependency. Given that the gecko branch for
epiphany is unmaintained and that other modules are waiting and
willing to use WebKitGTK+ I think this is pretty reasonable.

That being said in the end I just trust Joanmarie's judgment, she
being the professional here ;), and if she doesn't feel comfortable
with the current or expected a11y support in 2.28 I'll totally abide
her decission.


See the above "I'm just one person" comment. :-) I think at this point
we need the rest of the community to chime in.

Take care.
--joanie


Cheers, Xan


On the Orca side of things, I'm confident that when that list of bugs
has been addressed I'll be able to implement support. My concern (again)
is discovering additional issues at that point and it being too close to
the 2.28 release to do anything about them.

--joanie

On Tue, 2009-07-14 at 09:43 -0400, Willie Walker wrote:

Just to chime in here - based upon our experiences with Gecko,
accessibility support for browsers is no trivial task.  Xan and Joanie
have been hammering away at an impressive pace so far.

Joanie, Xan - what do you think it would take to hit 2.28?  Would more
people from the WebKit internals side help?

Will

Joanmarie Diggs wrote:

Hi all.

I think it's safe to say that implementing accessibility for something
as complex as WebKit is not a trivial task. :-) When I originally looked
at WebKit's accessibility a year or so ago, I was really concerned; now
I'm excited about it. Already there are things in WebKit which
JustWork(tm) and do so with little-to-no change in Orca -- things which
have taken (and in some cases continue to take) us much effort to
accomplish within Orca's support for Gecko. The work that Xan and others
have done has been awesome!

That said....

Below is a list of the currently open bugs and their impact on users. In
order for WebKit to be reasonably accessible for users of assistive
technologies, I believe that the majority of these bugs need to be
addressed. My concern first and foremost is can that be accomplished in
time for the GNOME 2.28 release? Beyond that, we don't know if anything
else of significance will be discovered while implementing support for
WebKit in Orca and other ATs, once these bugs have been addressed.

Therefore, as much as I hate to say this, my recommendation is that we
keep working at the pace we are to address all of these issues, but that
GNOME 3.0 be the release in which WebKit is included as an external
dependency.

--Joanie

25531:  Metabug: Bugs blocking Orca support
https://bugs.webkit.org/show_bug.cgi?id=25531
Bugs fixed:   15
Current bugs: 29

~~~~ Critical ~~~~
27097:  Segfault when examining an object of ROLE_TABLE via at-spi
Status: Unconfirmed
Impact: If a user is reading the text of a page and encounters an
        object of ROLE_TABLE, the browser will crash.

~~~~ Problems Navigating Through Text ~~~~
25415:  Please implement support for get_text_at_offset
Status: TONS of work has been done on this. Support for characters,
        words, and sentences seems to work quite nicely. Support for
        the current line sometimes works and sometimes does not.
Impact: If a user is arrowing through content by line, assistive
        technologies cannot present the current line reliably.

25677:  Implement support for get_character_extents and
        get_range_extents
Status: Unconfirmed
Impact: 1) Because WebKit exposes the text from links and formatted text
        as separate accessibles, a screen reader cannot just ask for the
        current line and get the full line. Instead, the screen reader
        will need to piece together the full line from individual
        accessibles. Because of this bug, a screen reader cannot
        identify if the text from one accessible is on the same line as
        another to present the full line contents.

        2) Orca's Flat Review mode cannot provide access to WebKit
        content.

25533:  Elements on the same line should be treated as such by caret
        navigation
Status: Unconfirmed
Impact: Because a screen reader must "piece together" the current
        content of a line by looking at the position of text objects,
        there is an assumption that pressing Up/Down Arrow will move the
        user by a full line. When that fails, the screen reader is in
        danger of repeating surrounding text, making it hard for the
        user to read and understand the content.

26991:  get_n_selections and get_selection fail when selecting text
        across object boundaries
Status: Unconfirmed
Impact: Users who are blind will have difficulty selecting text which
        includes links.

25676:  Problems navigating by caret in links whose text wraps onto
        subsequent lines
Status: Unconfirmed
Impact: A user cannot arrow left and right all the way through the text
        of a link which wraps.

25669:  Incorrect/missing caret-moved events when navigating across
        object boundaries
Status: Unconfirmed
Impact: If a user is arrowing left/right between linked and non-linked
        text, a screen reader cannot reliably present the new location.

25526:  Additional support is needed for caret browsing
Status: Patches proposed and seem to work nicely, need to be committed
Impact: Keyboard users cannot navigate and select text in content as
        expected

~~~~ Problems Accessing Forms ~~~~
25523:  The text displayed by push buttons is not exposed to assistive
        technologies
Status: Discussed, but not yet addressed.
Impact: When a user gives focus to a button, assistive technologies can
        only indicate that *a* button has focus; not *what* button has
        focus. As a result, a user who is blind will not know what a
        button is or does until he/she presses the button and sees the
        results.

25679:  Improve accessibility of focusable lists
Staus:  Unconfirmed
Impact: When a user moves around within a focusable list, assistive
        technologies cannot present the current item to the user. As a
        result, focusable lists are completely inaccessible to users who
        are blind.

25678:  Implement ROLE_COMBO_BOX
Status: Unconfirmed
Impact: Combo boxes are completely inaccessible to users who are blind.

25896:  Implement accessible text interface for objects of role
        PASSWORD_TEXT
Status: Unconfirmed
Impact: Screen readers cannot present the number of characters
        displayed, indicate when the caret has moved, or confirm when
        text has been inserted or removed. Password fields are thus
        completely inaccessible to users who are blind.

25535:  object:state-changed:checked events missing for radio buttons
        and checkboxes
Status: Patch attached, waiting for review
Impact: A user who is blind has no confirmation that he/she has
        successfully toggled the state of the current radio button or
        checkbox.

25898:  object:text-changed events should be emitted for entries and
        password text
Status: Unconfirmed
Impact: When the user types or pastes new text in an entry, or deletes
        text from an entry, screen readers cannot present the
        newly-added/deleted text. While this does not render entries
        inaccessible to users who are blind, it makes interacting with
        them difficult.

25530:  Implement support for accessible labels
Status: Unconfirmed
Impact: Given a properly marked-up form, a screen reader still cannot
        present the name/label of each form field receiving focus. As a
        result, a user who is blind will find it difficult to know what
        information is expected, especially for entries.

~~~~ Problems Accessing Tabular Data ~~~~
25534:  Objects of ROLE_TABLE should implement the accessible table
        interface
Status: Unconfirmed
Impact: Users who are blind cannot access tabular data efficiently and
        may have difficulty understanding the content due to the lack of
        table structure.

(See also bug 27097 - Segfault when examining an object of ROLE_TABLE
via at-spi)

~~~~ Other Issues That Really Should Be Addressed ~~~~
25411:  ATK accessible ancestry broken
Status: Unconfirmed
Impact: 1) Assistive technologies cannot ascend the hierarchy reliably
        within document content.

        2) Assistive technologies needing to know the toolkit associated
        with an accessible within document content cannot obtain that
        information.

27011:  Implement support for get_index_in_parent
Status: Patch proposed, has issues
Impact: Assistive technologies cannot reliably identify where any given
        object is within the accessible hierarchy.

25413:  Please expose the level of headings.
Status: Unconfirmed
Impact: 1) It is more difficult for a user who is blind to understand a
        document's structure because he/she cannot identify the level of
        headings.

        2) It is more difficult for a user who is blind to navigate
        efficiently through a large document whose content is arranged
        by headings at various levels because Orca cannot implement that
        support without knowing the level of headings.

25528:  Text attributes not exposed
Status: Unconfirmed
Impact: A user who is blind has no way to identify how text is
        formatted.

27048:  Implement STATE_FOCUSED, STATE_FOCUSABLE, and corresponding
        events for text objects
Status: Unconfirmed
Impact: An assistive technology cannot filter out extraneous events.
        Example: It will likely be difficult for Orca users to use an
        application's "find" feature due to the presentation of
        irrelevant caret-moved and selection-changed events.

25831:  Events missing when a document is (re)loaded
Status: Unconfirmed
Impact: Screen readers are not aware if the content of the current page
        is changing, or when it is safe to begin presenting the content
        to the user.

25524:  Expose the title attribute to assistive technologies
Status: Unconfirmed
Impact: Information presented to users via the title attribute is not
        accessible to users who are blind.

25525:  Tooltips should be fully keyboard accessible
Status: Unconfirmed
Impact: Tooltips (including information presented via the title
        attribute) are not accessible to users who cannot use a mouse.

27085:  Incorrect rendering of list
Status: Unconfirmed
Impact: Screen readers cannot always report accurate information about
        the number of list items or provide accurate "structural
        navigation" by list item.

~~~~ Minor/Would-Be-Nice Issues ~~~~
25673:  ATs should be able to select/unselect text
25675:  Formatted text should not result in additional/separate
        accessibles
25897:  Extraneous object of ROLE_PANEL in hierarchy for entries
25901:  ROLE_SECTION should be used instead of ROLE_PANEL for
        <div></div>

On Tue, 2009-07-14 at 12:09 +0100, Gustavo Noronha Silva wrote:

On Mon, 2009-07-13 at 21:37 +0200, Andre Klapper wrote:

If there have been changes/improvements/fixes compared to when this
module was proposed: Mention them.

In the last weeks we have had a fair number of fixes to the a11y support
in WebKitGTK+. I am not the best person to talk about them, but since
Xan is away for a while, I think I should bring this up.

I am sure there are still some bugs to fix, but it seems to me like the
major problems blocking are now fixed, or almost there, so we should be
able to get them done for a 2.28 release.

I think it's important to have some comments, and a list of bugs that
are blocking acceptance so that we can asses the viability of getting
all of them closed. Joanmarie, Willie, comments? =)

Thanks!


_______________________________________________
desktop-devel-list mailing list
desktop-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]