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.

-- 
Ubuntu-accessibility mailing list
Ubuntu-accessibility@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility

Reply via email to