SitePoint Sponsor

User Tag List

Results 1 to 8 of 8
  1. #1
    SitePoint Member
    Join Date
    Oct 2007
    Posts
    3
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    .net and screen reader accessibility

    Hi,

    I'm building a site at the moment that needs to be accessible, particularly for screen readers. Now, someone that knows way more than me about accessibility has flagged a potential issue I'm not sure can be got around. Apparently if a screen reader comes across a form tag it declares it as such, and jumps to the form elements. However with .NET the whole page, every page - is essentially a form. You can't just wrap form tags around several different elements of the page that could be forms.

    You can apparently switch to forms mode in the screen reader to counter this but it is messy (again not from experience, just been told it).

    Does anyone have any experience in making .net pages screen reader-friendly? It would be useful to have some examples if there are any of sites that are .NET and do this kind of thing well..

    cheers

    Alan

  2. #2
    SitePoint Guru Chroniclemaster1's Avatar
    Join Date
    Jun 2007
    Location
    San Diego, CA
    Posts
    784
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I can't point to any great sites myself, but I do have an interesting background. I'm a beginning to intermediate .NET programmer, and I've worked at a Blind Center and had the opportunity to test some of my designs with the blind and visually impaired.

    I don't think the issue you raise is a huge problem. Not a single one of the people who looked over my page in either Zoomtext (the most popular screenreader) or Jaws (the most popular voice output/braille display) even mentioned that particular issue. My Jaws users (I believe they're more applicable to your situation) tended to browse a page by reading the text, and if there was too much junk at the beginning of the webpage, they would begin skipping from link to link looking for something interesting. It sounds like the person who's testing your page out on a screen reader may do things differently. That may explain the difference, but that's what my experience has been.

    The biggest thing that you can do to make .NET pages screen reader-friendly is to use web standards based design. It's generally better for your SEO as well, just think of Googlebot as the world's most important blind user cause all your images and scripts don't mean anything to Google or the blind.

    The thing that works well about that technique is that it tells screen readers exactly what they need to know. The important part of web standards here is code separation. Structure in your .html/.aspx page, appearance in your .css file, behavior in your .js file. Using a layout tables can be problematic, the more complex, the more worrisome. But when your markup says <h2>Here's my heading</h2> <p>And here's the paragraph that follows.</p> Then the browser and the screen reader know that it's a paragraph, or a heading, or a list, or whatever. Someone with a screen reader can skip from heading to heading, link to link, etc. and your page is communicating properly with the screen reader rather than using font tags, blockquote tags to force indents, headings to center and bold text, etc. This doesn't give you any control over the appearance, but the flip side is that it doesn't interfere with the appearance. So all the appearance can be controlled from your CSS file. This is not necessarily the easiest in .NET especially Visual Studio. You have to avoid any of the inline style attributes which are so easy and seductive to set, but it causes conflicts if you're using CSS. I find you have to monitor your output very closely to make sure you understand how the .aspx page you're writing will output as HTML after the server gets through with it. I usually spend a moment to check View Source after every change or two that I make to a page. There are a couple other great tools out there. There's a set of CSS friendly adapters you can download and install into .NET; I wouldn't say they're ideal but they're a vast improvement. (There's even a new Wrox book out Professional ASP.NET 2.0 Design: CSS, Themes, and Master Pages I haven't had a chance to take a look at it but I want to because the CSS adapters are a whole chapter) There's also the new SitePoint book ASP.NET Anthology. I've seen mixed reviews, but the .NET & web standards chapter which is included in the free sample makes it clear that there's a lot of good information on best practices. Especially if accessibility is a key consideration for you.
    Whatever you can do or dream you can, begin it.
    Boldness has genius, power and magic in it. Begin it now.

    Chroniclemaster1, Founder of Earth Chronicle
    A Growing History of our Planet, by our Planet, for our Planet.

  3. #3
    SitePoint Member
    Join Date
    Oct 2007
    Posts
    3
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for that, actually, the HTML will be written using the best possible standards - luckily there's an expert doing that part. And all that will be happening will be that label fields will be populated with content from the CMS. So semantically it should all present very nicely - we were just more worried from the single form point of view and it navigating around say three different forms on the page - easy enough to do in .NET for a normal browser, with events on a button, but more complex when dealing with a screen reader (I think, anyway).

    There won't be any inline styles applied so that should be fine.

    cheers

    Alan

  4. #4
    SitePoint Wizard
    Join Date
    Feb 2007
    Posts
    1,274
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Note, if the page does not use any controls which can perform postbacks you can get rid of the "page" form entirely. It is only needed to maintain viewstate across postbacks/callbacks.

    When dealing with forms, ASP.NET automatically maintains field (and property) values across postbacks. You may want to use fieldsets to group fields together in "subforms" instead of using seperate forms. Screen readers should readily pick up the fieldsets.

    If you want multiple forms only one of them can be maintained by ASP.NET automatically (i.e. runat="server"). The other ones need to post back to some other handler which uses the Request object to access the posted fields.

  5. #5
    SitePoint Wizard bronze trophy bluedreamer's Avatar
    Join Date
    Jul 2005
    Location
    Middle England
    Posts
    3,267
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    It would be worth checking for accessibility/usability issues at each key stage of the project as well, correcting bits as you go along - this can save a lot of extra work in the long run.

  6. #6
    SitePoint Guru Chroniclemaster1's Avatar
    Join Date
    Jun 2007
    Location
    San Diego, CA
    Posts
    784
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Sounds like you're in good shape. I agree with both posts. Unless there's some burning reason that you need separate forms, fieldsets are the most semantic way to write that, and while I haven't had a project that required multiple fieldsets, accessibility is frequently cited as a reason for using them. I'm pretty sure that's best practices. I also believe in frequent testing, to avoid the massive bug that nobody noticed and is now so ensconced in the program that you have to go over every line of code to find it. Yuck! Also test it to the specs you want to live with. If that's meeting W3C A, AA, or AAA specs, test to that. If it's dealing with a particular group of individuals (the blind, etc.), get beta testers. Test it in as close to the real criteria you want it to meet. The closer you can test it, the less pain you'll have later.
    Whatever you can do or dream you can, begin it.
    Boldness has genius, power and magic in it. Begin it now.

    Chroniclemaster1, Founder of Earth Chronicle
    A Growing History of our Planet, by our Planet, for our Planet.

  7. #7
    SitePoint Member
    Join Date
    Oct 2007
    Posts
    3
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    thanks heaps for all your comments. Seems I'm not quite as snookered as I first thought on this, particularly as I can largely get away without needing the server side form within the CMS unless I'm rendering dynamic forms. Tested it and seems to work fine.

    Will be good to use this site for a test case to see how accessible .NET really is for ticking all the required boxes!

    cheers

    Alan

  8. #8
    SitePoint Wizard
    Join Date
    Feb 2007
    Posts
    1,274
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I asked one of my friends who is a blind (100&#37 developer. He uses Jaws - a very popular screen reader. He has not experienced what you had been relayed. He did say that Jaws has two modes: A "read" mode which reads out the html and a "write" mode where only the input fields and corresponding labels are read out. In the latter he can write in the fields and tab between them. If a fieldset is in use the "title" of the fieldset is read out for each field in the fieldset. This means that if you have a form with two addresses (like "from" and "to"), and you organize the fields in from and to fieldsets, the words "from" or "to" resp. will be read out for each address field. Same with table headers (th) elements.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •