Tag: Layout

A Visual Studio Quick Guide to Accessibility (Part 2)

In my previous post, A Visual Studio Quick Guide to Accessibility (Part 1), I discussed one particularly important accessibility feature. The use of keyboard accelerators is essential because many people use them to improve productivity. Making them visible is important because you can’t use a feature you can’t see. This post won’t cover all of the ideas and concepts for Visual Studio developers found in Accessibility for Everybody: Understanding the Section 508 Accessibility Requirements. However, it does provide an overview of the most essential accessibility features—those that every application should have.

The first feature is the tooltip. Every application should include a ToolTip control. You can then provide a description of every user-accessible control in the ToolTip property for that control. It’s important to stress user-accessible in this case. For example, you won’t provide a ToolTip property value for a Label in most cases because the Label simply marks a user-accessible control such as a TextBox. When the user hovers the mouse over the control, the application displays a helpful bit of information about that control. Screen readers used by those with visual needs also read each of the tooltips to describe the controls to the user. A few rules for using the ToolTip control are:

 

  • Keep the ToolTip text short. Imagine trying to listen to long diatribes about control functionality when working with a screen reader.
  • Make the ToolTip text specific. Tell the user precisely what the control is designed to do.
  • Emphasize the user’s interaction. Tell the user how to interact with the control, such as “Type the message you want displayed.” or “Click to display a message on screen.”


In addition to the ToolTip control, every control has three special accessibility properties as shown here.

Accessibility0201

These properties have specific purposes:

 

  • AccessibleDescription: A description of how the user should interact with the control. In fact, I normally use the same text as the ToolTip property for this entry and rely on the same rules for creating it.
  • AccessibleName: The name that will be reported to accessibility aids. I normally provide the same text that appears on the control’s caption, minus the ampersand used for the keyboard accelerator.
  • AccessibleRole: The task that the control performs. In most cases, Default works just fine. However, when your control performs an unusual task, you should choose one of the more specific entries so that the accessibility aid can help the user interact with the control.


Make sure you fill out each of the properties so that accessibility aids have the best chance of making your application useful to those who have special needs. In fact, it shouldn’t surprise you to discover that AccessibleRole is already filled out for most controls, so you really only need to fill out two properties in most cases.

The final two changes appear on the form itself. Whenever possible, assign controls to the AcceptButton and CancelButton properties. The AcceptButton provides a means of accepting the content of a dialog box or form by pressing Enter. On the other hand, the CancelButton property makes it possible to reject changes to the form or dialog box by pressing Esc. It’s true that you’ll find situations where you can’t assign a control to one or both properties because there isn’t a default acceptance or cancellation control, but this limitation applies to very few applications.

Accessible applications are significantly easier for everyone to use. Less experienced users can benefit from the inclusion of tooltips. Keyboardists benefit from the presence of keyboard accelerators. Adding these features isn’t difficult or time consuming, so all developers should be adding them.  Let me know your thoughts about accessibility and whether you’d like to see additional accessibility posts at [email protected].

 

A Visual Studio Quick Guide to Accessibility (Part 1)

One of the most important accessibility aids that also applies to common users is the keyboard accelerator (or keyboard shortcut). In fact, this issue figures prominently in both C# Design and Development and Accessibility for Everybody: Understanding the Section 508 Accessibility Requirements. Just why Microsoft decided to turn this feature off in Windows 7 is a complete mystery to me. All of the pertinent examples in Professional Windows 7 Development Guide include keyboard accelerators, but you can’t see them. I’ve received a number of queries about this problem and decided that this two-part post on accessibility for Visual Studio developers is really necessary.

First, let’s discuss the keyboard accelerator from a programming perspective. A keyboard accelerator is the underline you see on a button, label, menu, or other control. You press Alt+Letter to perform the equivalent of a click or selection with the associated control. For example, most people know that you press Alt+F to access the File menu in an application that has keyboard accelerators properly implemented.

To create a keyboard accelerator, the developer precedes the letter or number with an ampersand (the & character). For example, to make the File menu respond to Alt+F, the developer would type &File in the development environment. I’ve always strongly encouraged the use of keyboard accelerators as a must have for any application because many keyboardists are seriously hindered by an application that lacks them. In fact, you’ll find the keyboard accelerators used in the vast majority of my books, even for examples that aren’t related to programming in any way.

Second, some developers who feel as I do about keyboard accelerators are upset that adding them to applications no longer works (apparently). Windows 7 hides the keyboard accelerators for some odd reason known only to Microsoft. The Ribbon interface provides an equivalent when the developer provides it, but we’re talking about all of the applications (the vast majority) that don’t use the Ribbon interface. It turns out that you must manually turn the keyboard accelerator support back on. Follow this steps to accomplish the task manually:

 

  1. Open the Control Panel, followed by the Ease of Access applet. Click the Ease of Access Enter link. You’ll see the list of options shown here:Accessibility0101
  2. Click Make the Keyboard Easier to Use. You’ll see a list of options for making the keyboard easier to use. Near the bottom of the list you’ll see the Underline Keyboard Shortcuts and Access Keys option shown here.
    Accessibility0102
  3. Check this option and then click OK. The system will now display the underlines as before.

One of the biggest questions I had while working through this is whether there is a method for turning this feature on or off at the command line. There isn’t any WMIC command that I’ve found to make the change (nor any other command for that matter), so I’m currently trying to discover the associated registry keys. I’ve found one so far. The On value in the HKEY_CURRENT_USER\Control Panel\Accessibility\Keyboard Preference key must be changed to 1. However, that value alone doesn’t make the change work, so there are more keys and values to find. If anyone has some clues to provide me about this particular need, please let me know at [email protected]. In the meantime, I’ll continue looking for the elusive registry updates required to automate this change.

 

Using a Horizontal Web Site Layout

A friend recently wrote to me regarding an issue with Web site layout. Of course, I’ve dealt with Web design issues in a number of my books–most notably C# Design and Development and Accessibility for Everybody: Understanding the Section 508 Accessibility Requirements. If you look at most Web sites today, they all have three serious problems:

  • The line length is too long–forcing the eye to work extra hard to read the material because the eye loses track of the line and actually making it tiresome to review the material.
  • The page contains too much material, which makes it tiresome for anyone working with a screen reader to listen to all the material before finding the one bit of information actually required from the site.
  • The use of vertical scrolling is contrary to the historical use of horizontal scrolling. If you look at how people worked with scrolling in ages past, it was always horizontal, making it easier to read the material.

She even sent me two articles that describe the problem in greater detail. The first article is entitled, “Are Horizontal Website Layouts the Wave of the Future?” and points out that research shows that most people don’t even read the excess material on a Web site. If nothing else, the strong research showing that my efforts are being wasted would tend to make me rethink my design. The second article is entitled, “Horizontalism and Readability” and it places more emphasis on the historical approach to horizontal layout, rather than focus on modern research. I tend to prefer tested approaches to presenting information when I can get them (new ideas are fine for someone else to test).

Of course, a Web site is not the same as printed material. Trying to equate the two could very well be a mistake. Here is my take on how the mediums differ:

  • The method of presentation differs. You’re not relying on paper, you’re using a video screen of some sort and that does make a difference in how the reader perceives the material.
  • The environment differs. I don’t usually sit in my easy chair next to the fire when I read materials online. I’m normally in my office in a formal work environment.
  • The approach to reading differs. My paper reading environment is relaxed and long term. It’s nothing for me to spend an entire day reading a good book. My online reading is more like a sprint–I find what I need quickly and never read for more than a half hour at a time.
  • The technology differs. When I read a book, I get print in one size. So, if the print is less than appealing or causes eye fatigue, I’m just stuck with it. My browser allows me to change the font size a Web site uses so I can make the print eye friendly. Although, I would still recommend wearing reading glasses if you find that you’re experiencing eye fatigue from staring at a computer screen, but life should be made easier if you can alter the font size. In fact, I can even use a CSS file to change the typeface and other features for some Web sites.

The obvious question now is whether the two environments differ enough that considerations normally made for paper don’t apply to Web sites. My thought is that creating Web sites with smaller amounts of material, eye friendly design, and shorter columns are all great ideas, but I’m not completely sold on the idea of horizontal scrolling. Of course, every person or business has their preference about how they want their website to look, and that’s fine. That is what makes everyone different. Some may decide to design it themselves, whilst others may decide to enlist the help and expertise of somewhere like Plenty of Pixels – Pasadena Website Design to incorporate everything they want to see on their website. As long as you have all the information you need to attract customers, that’s all that matters. But horizontal scrolling? That’s another story entirely. What is your take on this idea. Let me know at [email protected].