I came across this post on silverlight accessibility quick start
While this is better than the mostly nothing that is out there in terms of making silverlight apps accessible, it falls far short of providing developers with effective ways/guidance/tips and tricks for making silverlight apps accessible.
What I don't understand is why the silverlight team doesn't fix very basic things like the textblock control not being accessible!!! either make it accessible or get rid of the control. The guidance that use a read only textbox instead just doesn't make sense to me and definitely much less to all those developers who have little or no exposure to accessibility related issues.
Subscribe to:
Post Comments (Atom)
4 comments:
That guidance is actually something we are revisiting (I work on the Silverlight documentation, and particularly on the accessibility areas.)
The answer is not as simple though as "TextBlock is inaccessible". The issue is more complex. The issue is that TextBlock is a nonfocusable element. What happens is that when a screen reader is used as an assistive technology to view Silverlight content, and there is a mix of focusable and nonfocusable content (there usually is) many screen readers will enter a mode where they fixate on ONLY the focusable content. This is the Forms mode on JAWS. In Windows-Eyes not sure the mode has a name but it is NOT the browse mode. When this happens, it is very hard for screen reader users to jump out of the forms mode and get to a browse mode again.
If the user managed to stay in the Browse mode though, the text in a TextBlock is perfectly accessible. It will read via either JAWS or Windows-Eyes navigation modes such as Read All, using arrow keys to read by line, etc. In this mode the behavior of Silverlight content is more like conventional, non-interactive HTML, metaphorically a document.
I think I am going to revise the guidance for text / TextBlock only in those cases where you have TextBlock and otherwise focusable items (buttons, input fields etc.) interspersed, and it is likely that the screen reader user will enter a Forms mode because they would be using the TAB key, or pressing ENTER over controls, and so on. For these cases only, it may be necessary to use something else like a Label control tied to a particular interactive control as a way to transmit any read-only text information that is critical. Read-only text box does have the stigma of reporting the incorrect "edit" role, and a Label or LabeledBy approach would be better.
Thanks for answering. There are several other things/problems that I keep coming across with accessibility, e.g. the textbox control does not have UIA implemented properly to report caret tracking and only richedit text box has it implemented. Combo boxes are not read properly by jaws or NVDA or anything else I've tried. Even the non-focussable textblocks being read just like html is something I've only seen in the latest version of jaws and does not happen with NVDA.
Also, as a developer, if I am creating a table in which each cell has 2 textblocks (bound using a data template to the underlying collection's two different properties), the most I could get jaws and NVDA to read was the first textbox. I need guidance on making complex data templates accessible, in addition to the basic silverlight controls and custom controls using UIA.
Lastly, can I send these kind of questions/problems to you or any group at MS?
Thanks again.
Hi Manish,
I need your help please share your e-mail id.
Regards,
Rahul
Post a Comment