As I mentioned here, I've been trying to solve a problem with a web browser control embedded in a Windows Form application. I found that if you use this method to pass the HTML page as a string, when the web browser control gets focus while tabbing, it will not release it until you click on the contents. Not usually a big issue, but when the spec for the form says it must be accessible without the use of a pointnig device, it counts! This was compounded by the fact that when the web browser did get focus, it would not let you scroll the page using the Page keys.
After toiling over it, I found that you have to do four things to make it work in an acceptable fashion (not necessarily the best way):
- Add an anchor to the page
- Add a form elements to the page
- Add some JavaScript to the page to give the form element focus
- Not pass the HTML in as a string
So what I did was:
- Write the HTML string to a temporary file, and load it in by calling the web browsers Navigate method
- Use the following HTML page template to give the form element focus when the page is initially loaded:
<html>
<head>
<title>a</title>
<script>function sf(){document.f.q.focus();}</script>
<style type="text/css">
INPUT { WIDTH: 8px; BORDER-TOP-STYLE: none; BORDER-RIGHT-STYLE: none; BORDER-LEFT-STYLE: none; HEIGHT: 18px; BORDER-BOTTOM-STYLE: none }
</style>
</head>
<body onload="sf();">
<form name="f" id="f">
<a href="#"></a><input type="text" readonly name="q" size="1"/>
</form>
</body>
</html>
Phew. And after all that, the user can tab around the windows form, and successfully get the web page to scroll if necessary. It's not pretty, it's not ideal, but it works. The only issue with it is that when the user is tabbing around the form, when focus gets to the web browser control the first stop is invisible (I'm assuming this is when the browser control itself has focus), the second is the form element, and the third is the anchor (when this has focus you can scroll).