Re: WebKitGTK+ as an external dependency

[Joanmarie Diggs <joanmarie diggs gmail com>]

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