Re: Feature proposal: Focus caret/tracking in GNOME Shell
On 11-10-22 8:25 PM, Matthias Clasen wrote: On Fri, Oct 21, 2011 at 12:25 PM, Piñeiroapinhe...@igalia.com wrote: Description === The GNOME Shell magnifier currently relies on Orca to track the current keyboard focus, scrolling the view of the magnified content to include the focused UI element or caret position. This is acceptable for the very few users who require both a screen reader and screen magnifier simultaneously. However, for the majority of magnifier users, who want to use only a magnifier, it is overkill to launch a screen reader as well. The shell should have its own focus tracking mechanism. Will this focus tracking mechanism be used for the shell OSK as well ? Yes, in the sense that the mechanism is neutral with respect to who can use it. So, it's not specific to the magnifier; the magnifier is but one of its users. -- joseph 'I had some dreams, they were clowns in my coffee. Clowns in my coffee.' - C. Simon (misheard lyric) - ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Proposed magnifier DBus names
Anyone, A group of us have been discussing names for a DBus magnifier service. We have come to a consensus. Service names: org.gnome.magnifier org.gnome.magnifier.zoomregion Object names: /org/gnome/Magnifier /org/gnome/Magnifier/ZoomRegion Do you see any problems with these names? -- joseph 'Clown control to Mao Tse Tung.' - D. Bowie (misheard lyric) - ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: WebKit and GNOME
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 - ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
