On 10.12.2009 22:03, Serge Tumanyan wrote:
> Hello, Stefan.
>
>>> 1. Combo box to select the repository - ControlID = 1029,
>> Alt-U should work?
>
> I have checked and it works, but for some reason the scereen readers do not
> see this hotkey - let me describe the situation - since we do not see the
> screen most screen readers have a special keystroke (for example
> Shift+NumPad 5 in JAWS) for announcing the hotkey. Imagine that to get the
> hotkey by travelling on the screen letter by letter and pressing a keystroke
> on each of them to get information if it is underlined or not - it is a
> nightmare. For other similar controls, like for example the two tabs from
> the discussed combobox there is an editor wiht ControlID = 1010 and the
> screenreaders see that hotkey assigned to it with no problems. So may be you
> have assigned the hotkey to that combo box a bit unusual? There is definetly
> a difference in assigning the hotkey to the combo box and to the edit box
> here that stops the screen readers from seeing the hotkey in the first case,
> though it is present...
That's not good. The hotkey is actually on the group box since the combo
box itself doesn't have a text. But according to the MSDN docs, screen
readers should do the same as Windows does and use the accelerator of
the label/groupbox that comes right before such controls as a combobox
in the tab order.
For example, a label in front of an edit control with an accelerator key
would set the cursor in the edit box. The same applies to the groupbox
'in front' of the combobox (again, in front applies here to the tab order).
Of course, I'm using the latest nightly builds (or my own dev builds)
and not the 1.6.6 release. Since there are many differences already
between those two versions it might be that this is the reason you don't
see the accelerator in your screen reader?
>>> 2. The next in tab order repository byutton ControlID = 1035,
>>
>> Since that button doesn't have a text, I don't know how to add an
>> accelerator key there.
>>
>>> 3. The next Repository button in the bab order with the ControlID = 1036,
>>
>> same here.
>
> There can be two methods:
> 1. Bad one - since hardly localizeable - using the CreateAcceleratorTable,
> DestroyAcceleratorTable - by this method the accelerators are hard coded
> inside the application.
> 2. The LoadAccelerators function that loads the accelerators from the
> resource attached to the Instance provided as the parameter - it is much
> better then option 1.
The accelerator table is globally and used for commands only. It can't
be used for selecting controls - unless of course we implement a
separate command for each control and set the focus to that control in
its command handler. But that would be a *lot* of work and would clutter
the code a lot.
>>> 4. Checkout depth combo box with controlID = 1373,
>> fixed in r17919. Use Alt-e in the next nighly build.
>
> Thank you, I shall check if the accelerator is visible with the screen
> readers.
>
>>> 5. The revision edit box with the ControlID = 1034,
>> doesn't have a text either.
>
> See the above discussion on accelerators.
It would be possible here to set an invisible label control in front of
the edit box which has the accelerator key assigned to it.
>>> The second thing to do is - to add some internal (non-visible) tags to
>>> the
>>> items in the listviews that you mark with the colour for the sighted
>>> persons. I noticed one example in the revision log dialogues - you mark
>>> already merged revisions with the gray colour - and it takes some time
>>> for
>>> the blind developer to distinguish between the merged and non-merged
>>> revision. There could be several ways here:
>>> 1. Adding MSAA information, where MSAA stand for Microsoft Active
>>> Accessability. I do not know exactly if you are familiar with MSAA - if
>>> not - I surely can help you with descriptions, testing of changes and
>>> answering questions on it.
>> Good idea. I'm currently reading the docs for MSAA and will make use of
>> it where possible and necessary.
>
> Excellent!
> The only thing I would like to mention here is that Microsoft provides some
> default MSAA for a lot of controls and for ListViews as one of standart type
> of controls. Please do not replace the original accName and accDescription
> property in listviews because a lot of internal code in screen readers is
> based on it and you can break it making the situation worse. I suggest for
> example to add the accValue property which is usually empty in ListViews for
> example setting it to 'Merged' or for example 'Already Merged' and this will
> be a good information for the screen readers and you will not spoil the
> default functionality.
Of course. Overwriting existing info is never good.
I'll have to investigate first how to set information to columns and
rows in a list control. From what I've read so far it seems only
possible to set such info on whole controls only, not sub items of a
control. But I'm sure that there is some way to do that, just haven't
found it yet.
>> I've also got the accessibility checker tool with which I'm now testing
>> the TSVN dialogs:
>> http://acccheck.codeplex.com
>
>
> Excellent, but please keep in mind that for the blind person the
> accessability is not only the information, but also easy accessing the
> functions that can not be checked by any accessability tool, since it is
> non-algorithmic (smile).
And that's where you can help. Just tell me how to improve the dialogs
and I'll do it.
>> The copy/move operations in explorer which TSVN provides via right-drag
>> can also be done with the explorer "Copy" or "Cut" (the normal copy/cut,
>> i.e., Ctrl-C or Ctrl-X) and then using "paste" from the TSVN submenu.
>
> Then this ability should be mentioned in TSVN documentation. When I have
> read the documentation there was a something like that you can only right
> drag the objects and this stopped me from the further investigation.
> Something like - those who do not like or can not right drag the objects can
> use standard copy/move command while pasting from the TSVN submennu will be
> enough I believe.
I'll add this to the docs.
>>> Additionally I shall provide you with exact location of controls that
>>> seems
>>> to lack accessability - if you do not mind of course.
>> Sure, just send a list of those and I'll add whatever I can.
>
> I shall send them by turn when I shall find inaccessability. Trust it is a
> better solution since I shall provide them in turn of importance, because I
> shall run into problems in my usual work and the fact that I have run into
> inaccessability means that this one is used more often then others. In this
> way we shall fix the problems step by step from more oftenly used to less
> common dialogues.
Of course, reporting the issues and improvements by importance is the
best way to go here.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2429594
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-12-10 22:27:09 CET