|
|
Thursday, September 10, 2009
If you just need a quick and dirty DropDownList of, let's say, Month values, you can simply build an ArrayList to populate it with, then bind the DropDownList to the ArrayList. This is simple and examples are easy to find on the 'net, but here's the trick: when creating ListItems for your ArrayList, give the ListItems both a Text and Value. Then set the DataTextField of the DropDownList to "Text", and the DataValueField to "Value". Then both the Text and Value properties from the ArrayList are populated into the appropriate fields of the DropDownList!
Here's the VB code:
Dim months As New ArrayList
months.Add(New ListItem("January", "1"))
months.Add(New ListItem("February", "2"))
months.Add(New ListItem("March", "3"))
months.Add(New ListItem("April", "4"))
months.Add(New ListItem("May", "5"))
months.Add(New ListItem("June", "6"))
months.Add(New ListItem("July", "7"))
months.Add(New ListItem("August", "8"))
months.Add(New ListItem("September", "9"))
months.Add(New ListItem("October", "10"))
months.Add(New ListItem("November", "11"))
months.Add(New ListItem("December", "12"))
ddlMonth.DataSource = months
ddlMonth.DataTextField = "Text"
ddlMonth.DataValueField = "Value"
ddlMonth.DataBind()
Thursday, November 06, 2008
I recently wrote an internal memo identifying accessibility problems with Telerik RadWindows for the website I'm currently working on. I post the items here hoping that they might be useful for some of you out there. Some of this is specific to our environment (IE6) and design standards but may be helpful for you too. Some apply to other modal window implementations as well.
1. Modal windows complicate the page. One of the primary axioms of designing for accessibility is simplification. I also experienced this first-hand when working with a visually impaired user: more stuff on the screen makes it harder to create a mental picture of the screen, and to navigate around and work with the screen.
2. Cursor focus manipulation is inconsistent. The screen reader reads from the cursor focus location on the screen. In order to help the user not to get "lost" on the page, when for example, checking a checkbox causes the screen to refresh, we programmatically force the cursor focus to be placed back on that same checkbox. Otherwise the focus would just land at the top of the browser in the address bar and since the user can't see that a page refresh happened, the user gets confused as to why the cursor moved there. In modal windows, even though the program code specifies that the focus should be set at a specific location, it works inconsistently for some reason.
3. The same focus manipulation issue exists for our standard for error/success messages, but is even worse. Setting the focus requires something clickable to set the focus on. Our standard design for messages places text on the screen which does not accept the focus directly. Setting the focus on a clickable page element directly above the message works, but only maybe 10% of the time for some reason. This is not only inconsistent, but dramatically so. As a workaround, we implemented messages in another popup (using Javascript) when they occur on a modal window. This helped, but is now inconsistent with messages elsewhere in the system.
4. Accessible solutions for modal windows are inconsistent with our standard page designs. Another axiom of designing for accessibility is consistency. If all of the pages behave and are laid out the same, even if the pages are complex, it becomes easier to use the system because the pages are familiar. As noted above, and in other situations as well, the guidelines that were developed for accessibility within modal windows are different than for standard pages.
5. RadWindows are not truly modal. Non-visual users are keyboard users. When working with a RadWindow, users can still tab onto and work with the parent page with the keyboard. The definition of a modal window states that the user cannot interact with the parent page while the modal window is active. Unfortunately, Telerik's attempt at implementing a modal window in the web environment falls short. It works for mouse users, as you cannot click on the parent page or any of its controls with the mouse while the modal window is active. But when using only the keyboard, you can tab onto the parent page, edit values on the parent page, and even submit information on the parent page while the modal window is active.
6. Implementing accessibility for modal windows is more time consuming than for standard pages. In addition to all of our standard developer guidelines for implementing accessibility, there are a number of additional guidelines for working with modal windows. Additional testing must also occur in development and QA.
We did some brief testing with the ASP.NET AJAX ModalPopup control and with modal windows that included some complexity, it had problem #5 as well, even though the online example does not. The ModalPopup would also have problems #1 and #6. I'm not sure about #2 or #3, and #4 is possible if accessibility was not considered in your page designs from the ground up.
Wednesday, August 27, 2008
When using TFS within Visual Studio, if you undo pending changes on an ASPX file by right-clicking on that file in Solution Explorer and selecting "Undo Pending Changes", pay close attention to the dialog box about what files are going to have their changes undone. TFS will not only undo changes on the ASPX file you selected, but will also undo changes for the code-beside file. I have lost my work a couple of times with this feature. Unfortunately, I don't know of a way to change that behavior. If you do, let me know!
Monday, August 25, 2008
In the last couple of shops I've worked that actually have documentation, what I have tried to accomplish with the developer documentation for the code was to be able to reproduce the code from the documentation. The documentation should give an overview of the page, contain all of the requirements and business rules in the Analyst documentation, and address all of the events that can occur on the page. How are fields populated? What gets validated when a button is clicked? If the application has multiple layers, all layers should be documented including the database stored procedures, user-defined functions, etc.
It's good to be able to do this type of documentation prior to release to the QA folks. Reason being, by giving the code this close of a second look, you often find stuff that was forgotten, is incorrect, or could clearly be done a lot better. Then it becomes part of the development process itself, not just an afterthought.
This of course is in addition to method header comments, self-documenting code (for example, naming variables and methods in such a way as to make the code tell you what it does just by reading the code itself), other comments in the code for more complex code or assumptions, avoiding the use of "magic numbers" (numbers in the code that have meaning but are not explained), and other coding best practices.
Monday, August 18, 2008
When designing a page in a web application, I have found that a page is more intuitive for end users if the page has a clear "Edit Mode" and "Read-Only Mode". With this design, the default mode of the screen is Read-Only, and the user clicks an Edit button to make the fields editable. The user then edits values as desired, clicks a Save button to save the values, and if everything saves properly, a success message is displayed along with the page in Read-Only Mode once again.
I have seen a number of designs where, when the user views the page, a number of page elements are immediately available to be edited. There are a limited number of times where this is expected. For example, a login page. Users don't expect to have to click an Edit button in order to edit the values in the textboxes for Username and Password. Another example would be a page that is one of a series of steps (Login is like this but is only one step) where the user enters the steps, and submits all of the information at the end of the steps. These pages follow the Read-Only/Edit/Read-Only design, but the Read-Only Mode is before and after the series of steps. Most other pages where information is being viewed and may or may not be edited should have an Edit Mode and a Read-Only Mode. Without this usability design, it is easy for the user to become confused.
This is not just a personal preference. We got some feedback recently from users who said that they entered information on a certain page, and when they went back to view the information later, it was not saved. These pages were designed without an Edit Mode and Read-Only Mode. Fields on those pages were always editable. The pages had a Save button at the bottom, but unless the user clicked it, they could edit the values then navigate away from the page and the new values would not be saved.
One possible fix for this would be to detect whether or not the user had made any changes on the page, then alert them with a (Javascript) popup when they navigate away from the page that they will lose any unsaved changes. The argument I have heard is that having an Edit Mode-only screen means less clicks for the user. But with this "warning on navigate away" solution, you have not reduced the number of clicks. It is also well known that users frequently ignore popup messages. But if you were to use this kind of solution, I would recommend making your error (and possibly, other) messages appear in popups throughout the application.
Monday, July 28, 2008
There are many areas where optimization may occur, and the resulting solution may be different for different areas of concern. In an ASP.NET application, delay may occur in the following places:
- On the client (within Javascript)
- Along the network between the client and the web server (lots of information on the page getting submitted, in ViewState or otherwise)
- On the web server during processing and/or rendering
- On any other application servers during processing
- Along the network between the web/app server(s) and the database server(s)
- On the database server(s) during query execution (including stored procedures, user-defined functions, etc).
For example, because a significant portion of our userbase is in a remote office with limited bandwidth, we found that it was most important for our application to optimize the time between the client and the web server. So even though it would have saved trips to the database (a common optimization technique), we took some stuff out of ViewState and are making additional database calls to retrieve it.
When attempting to make a decision between conflicting ASP.NET application optimization solutions, the area of concern must first be defined. Otherwise, you may be optimizing an already-sufficiently optimal subsystem.
Thursday, May 29, 2008
If you have the requirement to make your website accessible, unless you were given that requirement before you began the project, you will probably be converting an existing site. This was my task. After a lot of research, some work with blind users, and working with JAWS myself, here are the recommendations that I am presenting to our development team to make our ASP.NET 2.0 application more accessible. In another post, I will give some more detail about some of the specific solutions we developed.
Of course some of these recommendations are very specific to our website and our design standards. Your mileage may vary, but hopefully you'll find something useful. They are also not particularly organized in an optimal way, so you may need to read later items to know what earlier items mean. There will be more we need to do to make our website more accessible, but these are the items that were agreed upon to implement in this phase.
For a little background, our website is highly forms-intensive, and we make extensive use of gridview controls that allow editing of rows within the grid. We use fieldsets extensively as design elements. It is a secure website with a somewhat controlled, but large (>5000), user base. All of our users use IE. The system has a framework and a main portal page with modules that are available depending on the users access permissions. Currently about half of the modules are in production.
General Guidelines
1. CSS should be preferred for all presentation formatting. It is best to have a unified, consistent CSS scheme, but what is important is how the page renders. For example, specifying Height and Width on controls will render in a Style attribute, and this is OK.
2. XHTML 1.0, HTML 4.01 should be used everywhere. Use an HTML validator and minimize errors. ValidationSummary controls (which render as <div> tags) within a <p> fail validation, but they still render properly and look good.
3. Relative sizing should be used. In general, use “em” for fonts, images, and imagebuttons and “%” for gridview columns (ItemStyle-Width attribute in the templatefield tag) and controls (including width=”100%”).
a. Be careful that gridview grid lines don’t get shifted over.
b. For textboxes in grids use height=”100%”.
c. For some small textboxes that only take a few characters, it works better to size their width with an “em” value.
d. Make sure columns in grids will wrap if text with larger size will push grid to exceed page width. Do not change page width (for now).
e. If textboxes in grid cells with max length text in them push the grid off the right side of the screen (visible when editing a row, for example), consider using TextMode=”MultiLine”. If you do this though, the MaxLen property becomes useless and has to be handled another way (preferably with a RegularExpressionValidator).
f. Everything within the page should scale in size when the text size is changed (you can use Ctrl-mouse wheel to change the text size easily) but not stretch the bottom portion of the screen beyond the header width. There will still be a problem for or grids with a lot of controls.
g. Lookup controls and the custom images in bulleted lists will not scale.
h. Checkboxes do not scale.
4. Add a descriptive alternate text for all graphics, including imagebuttons. Master page logos should read "Our Company Logo", not just "Logo". The alt text for “Add New” buttons for gridviews are the same as the corresponding link text.
5. Set the focus to a logical place after postback.
a. For error and success messages, set the focus to MainContent after postback after submit via Javascript.
b. When adding or editing a row, set the focus to the first editable field.
c. Set focus on the same control if it causes an autopostback (dropdown lists, tabs, etc.). For RadioButtonLists, set the focus to the next appropriate control.
6. Do not use abbreviations. Screen readers cannot distinguish between abbreviations and full words. Acronyms are sometimes read properly if all characters are in upper case.
7. Multi-words should be broken down into their individual words. For example, ShortName becomes Short Name.
8. If tab order does not flow logically, specify tab index for controls.
9. The field name referenced in messages should match the corresponding column or label text.
10. All wording should be as concise and clear as possible, and should be complete sentences and follow proper spelling, grammar, and punctuation rules.
a. In messages, placing the field name first gives it emphasis.
11. Review all text including error/success messages to ensure conciseness, proper spelling, grammar, and punctuation. JAWS does not have a spell checker. If something is misspelled, it will be misread.
12. Sufficient contrast between foreground and background must be provided. Do not use a graphic background to provide contrast because if the user has graphics turned off, no contrast will be available.
13. On search pages, after clicking the search button and displaying the results, the search panel should collapse to just a link that re-opens the search panel. There are some simpler pages that may not need this feature.
14. Make sure that images used for links are reasonably large, preferably 32 pixels by 16 pixels or larger. Use standard or enlarged font sizes for text links, and avoid using text links that are shorter than four characters in length. Additionally, avoid placing small links close together. (CA DOR #1)
15. List accessibility contact information on the home page or contact page. (CA DOR #4)
16. Include any special instructions within field labels. (Sec 508(n), IOUCA 10c)
17. As part of developer testing, run JAWS on the screen.
Specific Guidelines
18. Add a “Skip to Main Content” link in master pages. It is a Hyperlink control with a ToolTip (but no text so that it is not visible) and is the first item on the page.
<asp:HyperLink ID="skipLink" runat="server" ToolTip="Skip to main content" NavigateUrl=""></asp:HyperLink>
this.skipLink.NavigateUrl = string.Concat(this.Page.AppRelativeVirtualPath, "#MainContent");
19. The first or main fieldset gets ID="MainContent" for the Skip to Main Content link.
20. Error and Success/Info messages:
a. All error and success messages should be placed between the MainContent fieldset tag and its legend tag. This causes them to display above the fieldset visually, but when the focus is set to the fieldset, the first thing that gets read by JAWS is the message.
b. Use labels for messages, not bulleted lists.
c. Use ValidationSummary controls with DisplayMode=”BulletList” for errors. HeaderText=”The following errors have occurred:”.
d. An asterisk (“*”) should display alongside the offending control, if possible. Error messages should not display alongside the offending control. In grid columns, leave enough room for the * to display next to the control without wrapping.
e. Call the FocusOnMainContent() BasePage method after every message that displays in a Label.
private void FocusOnMainContent()
{
System.Web.UI.HtmlControls.HtmlGenericControl htmlBody = this.Master.FindControl("body") as System.Web.UI.HtmlControls.HtmlGenericControl;
htmlBody.Attributes.Add("onload", "window.location='#MainContent'");
}
f. Call the BasePage method AccessibleError(IValidator, string) for every error message that displays in the ValidationSummary. In the IValidator parameter, pass the validation control that you would like to invalidate. If the error is specific to a particular field, specify an associated validator in order to make an asterisk (“*”) appear next to that field (assuming the validator’s text is set to “*”). If the error does not apply to a particular field, use a CustomValidator for the whole page.
this.AccessibleError(this.cvValidator, ErrorHelper.GetErrorMessage(100129));
<asp:CustomValidator ID="cvValidator" runat="server" Display="none" />
g. Similar to above for client-side error handling, for controls that invoke client-side error handling, add OnClientClick="validateAll();" Here is the validateAll() method (from the master page):
<script type="text/javascript">
/* After validation, reposition page to its main content. Primarily for screen readers. */
function validateAll()
{
var valid = true;
for(i=0;i<Page_Validators.length;i++)
{
ValidatorValidate(Page_Validators[i]);
if(!Page_Validators[i].isvalid)
{
valid = false;
}
}
if(!valid)
{
window.location='#MainContent'
}
}
</script>
h. Consolidate all messages of the same type (error, success) into the same control. If client-side validation is occurring, this means invalidating a client-side validator on the server for all errors.
i. Encompass the message label and ValidationSummary in a <p> to make them more noticeable. This will cause an HTML validation error due to nesting a <div> within the <p>, but it still renders and reads correctly.
21. Use divs for layout, but if there is a data table, do not mock it up using divs. Use an actual HTML <table> with <th>, <tr> and <td> tags as appropriate.
22. For search screens, at least two levels of searches should be provided: Basic and Advanced. (WCAG 13.7)
Specific Controls
23. Add the UseAccessibleHeaders property to all Gridviews. Specify the AccessibleHeaderText on the TemplateFields for more descriptive column names where needed. For checkboxes in grid cells, make the AccessibleHeaderText, for example, “Active Checkbox”.
24. Add a summary for each gridview programmatically in Page_Load:
this.gvMyGridView.Attributes.Add("summary", "summary text"); (Use lowercase “summary” to avoid an HTML validation error.)
b. In addition to a brief description of the gridview, include all column names and what kind of data are in them, a note about the edit/save and delete/cancel imagebuttons (where applicable). Also explain any peculiarities with the grid, such as nested grids or abbreviations in header text, to help a non-visual user to understand it.
c. The newlines (“\n”) in the text below facilitates line-by-line text scanning by JAWS users.
d. For grids where column headers are links that allow the grid to be sorted, add a note in the grid summary indicating this. For example, “The column header text is a link that sorts the table on this column.”
e. For dropdown lists, in the summary, refer to them as combo boxes, because this is how JAWS refers to them.
25. For Label controls, use the AssociatedControlID property where applicable. If an ASP Label is not required but the text is associated with another control, use an HTML label tag and its “for” attribute.
26. Consider making link text understandable out of context. JAWS allows the user to bring up a list of all links to facilitate navigation, but in that list, the links are totally out of context. If the link just says something like “Edit”, it is not apparent to the user what the link does.
27. Dropdown lists: If the text fits, put “Select Level” (or whatever the field name is). Otherwise, put just “Select”. If editing a grid row with a dropdown, the text that displays should be the previously selected value. If the dropdown is then optional, it should have “Select” or “Select fieldname” selection. If it is not optional, no empty selection should be available. In some cases, instead of “Select Level” the dropdown may take the place of a corresponding label, such as Time: “Select Hour” “Select Minute”. If there’s not enough space for “Select fieldname”, just the fieldname can be used.
28. Buttons should have AccessKeys added. For now, the button text will not have the letter underlined (this would require using an HTML button tag). Not used for imagebuttons in grids.
29. Telerik dropdown checkbox lists should not be used. Use a checkbox list or listbox instead. Avoid checkbox lists when the number of selections may exceed 5.
30. Lookup controls should have Tooltips added programmatically (cannot be done in aspx). This should already be done in the lookup user controls themselves. Also note that Lookup controls will not scale.
31. Images and imagebuttons do not need both a ToolTip and an AlternateText. Prefer ToolTips for added usability.
32. On RadDatePicker controls, add Date-Input-Font-Size=”1em” for proper scaling.
33. ValidationSummary controls should be set to Display=”BulletList” and HeaderText=”The following errors have occurred:”. They should be within a <p> along with the label control that is used for messages, and be placed in the code between the first/relevant fieldset and its legend. Visually it will display above the fieldset, but JAWS will read it first when focus is redirected to the fieldset.
34. For Validators, the Text should be “*” and come after the control it validates with no line break (or wrap). Ensure that enough room is left within columns for not only the control but the “*” from the associated validator(s).
35. Until more research is done on RadWindows, do not use them. Possible alternatives include: same page, new panel; separate page with link back to original page; new, modal browser window; perhaps the new Telerik will allow us to jump to the RadWindow consistently.
36. Do not use nested grids. Possible alternatives include putting the child grid in a new panel beneath the parent grid, “collapsing” the parent grid to only show the selected row (similar to Mall Sites, Units, Classrooms).
Notes
37. Although accessibility guidelines state that the application must be usable without Javascript, because we have a somewhat controlled user population, we are enforcing that our users must have Javascript. There is no need to code for users who do not have Javascript enabled.
Suggestions
38. Re-do the CSS for the entire site to unify and standardize it. Currently every module has its own CSS. This will also facilitate CSS being used more frequently.
39. Consider a fluid layout where the width of the application scales to the browser width.
40. Consider adding visible text that describes that certain fields are required, etc. Try not to let the user get an error as a way of figuring out how to use the screen.
41. Eliminate reliance on device-dependent Javascript. Certain Javascript events such as mouseover assume the user is using a mouse. Use onclick instead, where the user can use either a mouse or a keyboard (or other assistive technology).
42. Provide a site map for the site. (WCAG 13.3)
43. The menu system should be changed so that it is consistent throughout the application. The menu items that change depending on the current module should be moved to a sub-menu system. Also consider providing pages that can be navigated to for every link on the menu. (WCAG 13.4)
44. Some minor re-working should be done to standardize the UI for all pages. (WCAG 14.3)
45. Eliminate in-grid editing. Place only unique identifier in the grid, then open an edit panel with all of the data items in a vertical layout.
Wednesday, April 30, 2008
Like many organizations, we didn't find out about our Accessibility requirements until the application was half done and partly in production. It's one thing to know up front that you will have these requirements and build them into your UI designs. But getting those requirements late in the game has additional challenges.
When you find out that Accessibility is needed, the following steps can be taken without any impact to the application from a user's perspective (if done well), but will lay some groundwork for future Accessibility changes.
- Develop a CSS scheme and utilize it consistently throughout your application for all presentation formatting.
- Develop UI standards that are consistent throughout your application. Be as complete as possible and include anything that shows up on the screen: tags and controls, error messages, form elements, etc.
- Follow best practices with regards to separating business logic from presentation code to minimize the impact that UI changes will have on website functionality and business rules.
- Perform usability reviews and testing to make the site easier to understand and use. This will benefit all users.
- Optimize the UI by removing any extraneous code that was not previously cleaned up.
By following the above recommendations, you will be well on your way to Accessibility, and when UI redesigns are decided upon, they will be quicker and easier to implement.
Monday, April 28, 2008
Over the last few weeks of working with, and developing an ASP.NET application for, use with JAWS, I've found a few JAWS keystrokes to be particularly helpful. (For those unfamiliar with JAWS, it is the industry-leading screen reader software for those with visual disabilities.)
- The Control key. I call this the "shut up" button. It stops JAWS from reading. After a while you'll find yourself using it a lot.
- Insert + Down arrow. This causes JAWS to begin reading at the current JAWS cursor position.
- Tab (and Shift + Tab). When working with web forms, this is a commonly used key. It jumps the highlighted cursor between form elements.
- Insert + Z. This is a toggle for something called Virtual PC Cursor mode. It basically switches you between entering keystrokes that are interpreted as commands to JAWS vs. entering keystrokes to interact with a web application.
- Arrow keys. Right arrow reads the next character. Left arrow reads the previous character. Up arrow reads the previous line. Down arrow reads the next line.
- Control + Alt + arrow key. Our web application uses a lot of GridViews that get rendered as tables. JAWS has some nice table reading features. Control + Alt + Right arrow reads the next table cell. Control + Alt + Left arrow reads the previous table cell. Control + Alt + Up arrow reads the next cell directly up from the cursor. Control + Alt + Down arrow reads the next cell directly down from the cursor.
I was lucky enough to be selected to spend a day with one of our non-sighted users. It was a very enlightening experience and I gained a lot of perspective. She was not trained or very knowledgeable regarding JAWS, although she was very tech savvy and able to use the computer quite efficiently in general.
Not knowing any of the special keystrokes in JAWS, she tended to use the Tab key and the Arrow keys for almost everything (except for button or link clicks which are accomplished with either the Space Bar or the Enter key). I was surprised that she was not more fluent with JAWS, but like any sighted user who considers themselves computer literate, she had just jumped into things and figured things out by trial and error.
For some more perspective on using JAWS from a non-sighted user's perspective, the following article is worth your time: Guidelines for Accessible and Usable Web Sites: Observing Users Who Work With Screen Readers
Thursday, April 24, 2008
This is not a complete list of the accessibilty features available with a GridView, but this is what we're doing to make ours more accessible. (Note: At this point, we are primarily focused on users who use JAWS.)
- UseAccessibleHeader="true"
- Property of the GridView itself
- When the GridView is rendered as a table, using this property formats the header (first row) of the table using <th> tags instead of <td> tags. When navigating through the table with JAWS, the column header is announced prior to reading the contents of the cell.
- AccessibleHeaderText="Description of the column"
- Property of a TemplateField
- When announcing the column header as described above, this descriptive text is used instead of the typically terse column headertext. It should remain concise, but will give non-sighted users a better idea of what the data item is.
- Summary attribute
- This property is not available in the aspx, but during page_load (or equivalent event), the Summary property can be added to the GridView with the following code (C#):
- this.gvMyGridView.Attributes.Add("Summary", "List of Products");
- As the page reader progresses through the rendered HTML, when the table (GridView) is encountered, the Summary is read prior to the table header and rows. This helps to give the user an overview of the data contained in the GridView.
- RowHeaderColumn="ColumnID"
- Property of the GridView itself
- This is a nifty feature that allows you to define the data in all rows of the specified column to render as <th> tags so that the non-visual user would hear both the column and row headers announced when traversing the grid. Unfortunately, it is not available when using TemplateFields (which is primarily what we use), so we were not able to use this property.
- Remember to use CssClass attributes for the style properties (HeaderStyle, SelectedRowStyle, RowStyle, AlternatingRowStyle, etc.) to conform to the guidelines that recommend using StyleSheets for all formatting so that it can be easily overridden or disabled by users with limited sight.
|