Improving Gnome Desktop Accessibility
Francesco Fumanti
francesco.fumanti at gmx.net
Wed Mar 3 12:49:58 GMT 2010
Hi,
On 03/02/2010 10:07 AM, Jacob Schmude wrote:
> Hi
> I'm confused about some of these. My thoughts inline under each bug
> mentioned:
>
> On Tue, 2010-03-02 at 13:54 +0530, Arky wrote:
>
>> Clock-applet inaccessible (regression)
>> https://bugzilla.gnome.org/show_bug.cgi?id=581351
>> Yes, this one is definitely an issue. The time can be read but the calendar and the weather sections cannot.
>
>
>> Notification Area icons are inaccessible
>> https://bugzilla.gnome.org/show_bug.cgi?id=611562
>> Not true. Pressing ctrl-f1 on an icon will reveal its tooltip. If the icon has none, that is something the applet designer needs to correct. So they aren't so much inaccessible as they should be streamlined, i.e. ctrl-f1 should not be necessary.
>
>
>> panel_toplevel_construct_description should provide less technical descriptions
>> https://bugzilla.gnome.org/show_bug.cgi?id=610000
>> Why? These messages are informational. They tell you where the panel is, its state (expanded/collapsed) and its alignment. I'd rather have this information than not, it's been helpful when fixing systems for friends who are sighted.
>> "Desktop" name is now "x-nautilus-desktop" (regression)
>> https://bugzilla.gnome.org/show_bug.cgi?id=555425
>> Cosmetic, isn't it? Besides, it's accurate. You are in X, the underlying file manager is Nautilus, and you are on the desktop.
>> "search:" name instead of
>> "x-nautilus-search"
>> https://bugzilla.gnome.org/show_bug.cgi?id=610789
>> See above.
>> Pathbar 'drive' 'previous folder' icon inaccessible
>> https://bugzilla.gnome.org/show_bug.cgi?id=610809
>> I don't understand this one. In nautilus, on the toolbar, I have the back button as I should when I tab to it. If by the pathbar you mean the little buttons for each folder, well the previous folder is right to the left of the current one, how difficult is that? It's even named.
>> Switch to notification area shortcut key
>> https://bugzilla.gnome.org/show_bug.cgi?id=611563
>> A bit redundant, seeing as how all we need do is switch to the appropriate panel and tab straight to it. The solution to accessibility issues is not overload the user with additional keystrokes.
>>
> Personally, I think we have bigger fish to fry than cosmetic issues.
> Gksudo needs replaced or fixed, no program should be able to block
> at-spi (gnome-keyring-ask, I'm looking at you).
I completely agree with you about gksu and I am wondering whether gksu-polkit could not be a candidate that could replace gksu. That's why I tested gksu-polkit 0.0.2-1 with synaptic few days ago on the lucid development version; but it eats 100% cpu. :-(
The goal would be to ask on the Ubuntu devel list whether they could consider doing the replacement. But as long as gksu-polkit does not work properly, it will probably not make sense to ask for it.
> How about Webkit and the
> inaccessibility that big change pulled in? When you come right down to
> it, why is enabling the accessibility framework even a choice? It should
> always be on and ready to be used if you want a system to be truly
> accessible, so that all one need do is fire up
> Orca/gok/insert-at-of-choice.
Having at-spi enabled by default is something that gets regularly proposed to GNOME as far as I know; let's hope that at-spi2 will have less issues so that having it always running can finally be the default.
Cheers,
Francesco.
More information about the Ubuntu-accessibility
mailing list