Screen readers like NVDA implement two modes of operation: Browse Mode and Focus Mode.
Browse Mode is for reading a website/document/application. The screen reader will read all visible contents.
To interact with the website/document/application, Focus Mode offers some advantages: only the interactive content parts are read. In a website, this would mean that links, buttons, forms and navigation are read, but normal text is not read.
In NVDA, you can usually switch between Browse and Focus mode with Insert+Space, which is then confirmed by a sound. This works in most applications: Browsers, Windows Explorer, Skype, VS Code.
However, in my own WPF application (which e.g. has accessibility labels), when I press Insert+Space, nothing happens. NVDA seems to always be in Focus Mode, and there is no Browse Mode.
Intuitively this makes sense, because for Browse Mode, the screenreader needs to "know" what elements it should read, and in what order.
I have no clue where to begin implementing it. Is this a common WPF problem? Is it a problem of NVDA, which somehow needs to know that the application is capable of Browse Mode?
Is it possible you built your application with the accessibility compiler option turned off? Here are a few things you can check:
Accessibility switches in .NET
Example of solving an accessibility issue in .NET
Using Accessibility Insights to inspect accessibility properties in a WPF
If you run the built-in calculator app on Windows, it has the same problem as your app. You're always in forms mode and Ins+space won't switch to browse mode. However, there isn't really any "plain text" to read in the calculator app. Every element is an interactive element.
However, the Settings app does have some plain text and it has the same problem too. I can navigate to all the interactive elements but I can't get to the "Get even more out of Windows" text or the text underneath it. Visually it looks like a heading followed by a paragraph but switching to NVDA browse mode doesn't work.
Seems this is the way NVDA detects accessibility of an application:
Normally, NVDA uses the IAccessible2 API to get accessibility information from Chrome. With this embedded version of Chrome, NVDA seems to be unable to query the IAccessible2 interfaces and falls back to plain IAccessible/MSAA. I've seen this in embeded Chrome versions in Qt as well. Pretty sure it is a problem in the embedded version of Chrome.
Source: https://github.com/nvaccess/nvda/issues/13493
Related
In a standard WPF app, I have a WebBrowser control which has been navigated to a HTML5 sample page (http://ie.microsoft.com/testdrive/Browser/BrowserSurface/).
In the browser outside the app, I can interact with this site as expected – move photo’s around, use gestures etc.
In the WebBrowser control the site does not work as expected. It renders, but it does not respond to any touch gestures – It will, however, zoom in and out when I pinch.
Is it possible to make the WebBrowser control pass gesture events etc so that I can interact with the site as I would in a normal browser?
Many thanks for any help with this!
Kris
I know this is an old question but I think this has something to do with the fact that the WebBrowserControl standard uses IE7 ActiveX. I had the same problem which always gave me JavaScript errors in the control for TouchEvents.
After I added some registery key to force the WebBrowserControl to use the latest IE version installed it worked.
Here is what I've add to my registery. Paste it in a txt file and save it as an .reg file. Then DoubleClick it. Or enter the key/value manual in your registery via Regedit.
I even included this in my application code to add the key/value automaticially if it doesn't exist yet.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION]
"RetailTestApplication.exe"=dword:270f
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION]
"RetailTestApplication.exe"=dword:270f
Sorry, the code plugin srews up.
Change IE version for the WPF WebBrowserControl
MSDN Internet Feature Controls (B..C)
We are building a Windows application in .NET and one of its requirements is touch screen monitor. Other than that, it's a normal windows form based application. But except for making UI items little bigger for touch, I can't find anything I as a developer need to do for the requirement since touch screen is basically mouse operations. Am I missing something?
No, you are not missing anything. Do get the actual hardware hooked up so you can test it, "little bigger" is invariably underestimating the problem of fat fingers. Everything should work from a single click, right-clicks are horribly impractical, double-clicks are best avoided.
The only other thing you'll want to do is go into the Control Panel + Display applet and change the size of standard Windows UI elements. Pick a large window caption font if you want to allow the user to drag or close windows. Make the scrollbars at least twice as wide. And the menu and message box font. Go in the Mouse applet to increase double-click range and time if you want to support that.
If you do not need touch-specific event handling I think it's all you have to do. But touch means more than that and you may want to support it in a better way: http://archive.msdn.microsoft.com/WindowsTouch/Release/ProjectReleases.aspx?ReleaseId=2127
I am trying to add some shortcut handlers like Ctrl+B in my Silverlight application.
However, in IE when we press the Ctrl+B, it comes out a child window of " Organize Favorings". Is it possible to disable these browser shortcuts with Silverlight?
Many many thanks!
Mrainy
I'm not sure you can judging by what I've read. You may be able to hack it with javascript code on the page that passes it on to the silverlight application, however. (See javascript/silverlight interop)
If you need to use common shortcuts in your application perhaps you should consider running it in Out of Browser mode.
You can find out more about OOB on the MSDN:
http://msdn.microsoft.com/en-us/library/dd550721(v=vs.95).aspx
http://msdn.microsoft.com/en-us/magazine/dd882515.aspx
I have an app which I need to make accessible for Windows Touch. It is not a multi-touch application. I've looked at Microsoft's guidelines for touch applications which is interesting. There is one thing I am not clear on though, that is text input.
I would like a keyboard to appear when I click in a TextBox field. Is there a way to use the built-in on screen keyboard for this?
The first monitor I tested with was a Wacom. It is an older unit that uses a pen. It had some software that pulled up an on screen keyboard whenever I clicked in any text field (in any application). It was very handy. I thought this feature was using built-in Windows Tablet software because it didn't look like it came from a third party. A newer monitor I just purchased (Elo) does not have this feature though.
Answering my own question so it won't show up as unanswered any longer... From my comment above:
Looks like I've found the problem. The general purpose driver for the monitor wasn't installing it as a Tablet PC monitor. The Windows 7 only driver will provide a Tablet PC control panel settings. Now a keyboard shows up whenever I click in a TextBox field. The Windows XP compatible driver must have been using a legacy sub-system...
I'm relatively new to the WPF world and I'm working on an application where I need to have multiple windows in one application. Like Photoshop when the user clicks on "New" button a new window opens and the old existing window(s) goes in the background. The toolbar and the statusbar, however, stay on top, untouched.
I would also like to add the feature that the user can work with multiple windows if each of them is not maximized.
How do I achieve this?
I apologize if I'm a bit unclear in framing my question.
What you are (probably) talking about is an MDI Application. "Unfortunately" WPF does not support that natively. I use quotes because it is more frowned upon in modern UI development than it was in the past.
Instead, the most common "WPF way" of doing this is to open each New window in a new tab in a tab control (like Visual Studio and most web browsers do).
If you really want to do an MDI application, Google search that, but to warn you, it probably means creating your own Window manager.
An alternative is to open non-modal windows, with their ShowInTaskbar property set to false. This gives you the ability to open as many windows as you want, but you lose the ability to contain them within a centralized workspace app.