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).
Stefan, at last I have understood the problem.
1. You have wrapped a combo box into a wrapper with the window class
'ComboBoxEx32'. and this stops the screen reader from getting the
information. If you place the static text field inside the wrapping window
or totally will remove the wrapping window the situation should become much
better.
The windows sequence must be the following:
Static label (the one you already have)
Combo box itself (The window with the class 'ComboBox').
+-- Edit box inside the combobox (the window with the Edit class inside the
combobox)
This sequence can be wrapped whatever you want.
And now we have:
Static label
The combo box wrapper (the window with the class 'ComboBoxEx32')
+-- Combo box itself (The window with the class 'ComboBox').
+-- Edit box inside the combobox (the window with the Edit class
inside the combobox)
And this messes up the screen readers. Is it possible to move the static
label inside the wrapper class or remove the wrapper totally?
Hope that I have drawn the branches correctly visually...
> 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?
May be, if you have already changed the window structure?
>>>> 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.
Ok, it is not that problem here - if you can focus on the previous control
it is easy to press Tab once, so it is not that importance.
>>>> 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.
Well, yes, you are right. It is not totally important here since you can
focus on a radio button with the accelerator and tab once to get into Edit
box, so if you will fix - it will be good, but if not, well, we can live
with 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.
Here I can help you, since I am very familiar with MSAA. MSAA gives you its
own structure of objects that may/may not be dependant on window structure.
1. For buttons, checkboxes, edit boxes, combo boxes the MSAA provides only
one end object - the one that represents the control itself.
2. For listboxes, listviews, tree views and some other controls the MSAA
provides the object representing the control itself and provides some kind
of children of that object providing info for each item in the control. You
can access these children by simply providing the number of the child you
want. For example: oList.Get_accName (1) will access the first item name and
oList.Get_accName (10) will access the tenth element without paying
attention if it is visible. This how it works from the client side - the
screen reader. From the server part you have to provide the property
accName, accDescription, accValue reacting on the integer that is passed to
the method Get_accValue and providing the information to the client.
Returning back to our case you need from the server side provide the
accValue property with paying attention what is the number passed to it and
setting up the property accordingly to the information in the listview item
corresponding to that integer.
If any additional questions on using MSAA do not hesitate to ask - I shall
always answer if I know of course...
>>> 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.
I am eager to and do want to do that. Thank you for taking such users into
account.
>>> 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.
Ok, thank you.
>>>> 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.
Ok, I shall provide information about the commit dialogue tomorrow - have to
earn a living right now...
Thank you.
Serge.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2429617
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-12-11 03:31:27 CET