Home » Posts tagged 'web'
Tag Archives: web
Qualtrics, as an online survey tool, is useful for creating a survey link that you may post to a website. We often set up those web links for students to submit requests for assistance or information. An easy way to know that a student has submitted a survey is to set up an email trigger for the survey within Qualtrics. Instead of logging into Qualtrics to check your responses, you will get an email with the response data in it each time a student submits the form or survey. If you prefer to see your data in the normal reporting views within Qualtrics, it will collectively be there as well. Another advantage to the email triggers, is that the email allows you to retain a copy per submission for a student’s individual file. Requests for accommodations is one use case that comes to mind.
Let’s look at how to set up an email trigger.
- Go to the Edit Survey view.
- Click in the upper right on your Advanced Options menu button (shown below).
- Select Triggers, then Email Triggers.
- The email form appears with your email address in the TO box. You may change that if needed.
- You may add a FROM name or a default Qualtrics one will be used.
- Defaults for “Send Immediately” and “Include Response Report” are already selected.
- If you would like to add “Show Full Question Text”, you may select that as well.
- Click the “Save Triggers” button in the bottom right.
Additional information on Qualtrics triggers may be found at this website, http://www.qualtrics.com/university/researchsuite/advanced-building/advanced-options-drop-down/email-triggers/
Recently I have been working with two systems that allow a user to create, store, and share documents over the internet. In general terms both of these applications are “accessible”; however, there are some noticeable differences in the usability of the interfaces. The point of this article is to discuss the differences between usability and accessibility of web applications. I do not want to dump on any specific application so I will not use names for the article. Application A is the system I have been using for longer and Application B is new to me.
The most obvious area of difference between the two applications is in navigation of the interface. Both applications have access keys assigned to various controls in the interface. The idea of these controls is to make it easy to move around the interface. The challenge with this approach is due to the way these access keys are implemented in the real world. Screen readers and screen enlargers have many hotkeys that are used to move around the operating system and sometimes to navigate specific applications, such as web browsers. The problem for the creator of access keys is that each screen reader or screen enlarger manufacturer uses a different set of hotkeys. Unless there are very few defined hotkeys there is a good possibility that the assistive technology and some of the access keys will conflict. Most screen readers and screen enlargers have some sort of a “pass through” keystroke so it is usually possible to still use access keys. The challenge is for the user to remember the hotkeys for the screen reader and screen enlarger along with the hotkeys. The challenge is compounded if the user uses more than one screen reader or screen enlarger. For example: I use one primary screen reader at work. Due to cost I use a different screen reader at home. I occasionally use a Macintosh, which has a different screen reader. I use my iPhone for interacting with these web pages as well. The Mac and the iPhone screen readers are similar; but, not identical. I also use a screen enlarger program. Each one of these assistive technologies uses a different set of hotkeys and each has different access keys it conflicts with. Firefox also adds a Shift to the access key to try to avoid conflicts. The idea is a wonderful idea; however, the new access keystrokes still can conflict with the assistive technology. They just conflict with different hotkeys. Usually I don’t use the access keys and I fervently hope the access key does not accidently get activated when I am trying to interact with the assistive technology.
Application A uses headings to separate different areas of the interface. This is much easier to navigate. All that is needed is a knowledge of how to navigate by heading for the screen reader or screen enlarger that is being used. There won’t be any key sequence conflicts. Application B does not have headings built into the interface. The user must either remember the access keys or tab around the interface. Eventually I will probably work enough with Application B to figure out the access keys; however, I would probably not bother except I need to use this system to access some documents.
Another challenge that seems to be a frequent issue with web applications is the use of form elements. Both application A and Application B have some issues with this. Application A seems to have fewer issues. The issue is mainly that some controls that are logically grouped together are not the same type of element. For example, a page might have controls for “Save Draft”, “Preview”, and “Publish.” The “Save Draft” and “preview” buttons might be form buttons. The “publish” control might be a link with a background image. Usually this seems to be a method to make the more important control stand out from the other options. Users of assistive technologies frequently have to know what type of element they are looking for to more easily find it. The “Save Draft” and “preview” buttons will show a list of form elements. the “Publish” link would show on a list of links. All of the controls might be accessible; however, the logic of the controls grouping is lost due to the way the controls are implemented.
Tables can be a great help and also cause accessibility issues, depending on how they are implemented. Some information such as web-based file management can work very well in tabular form. Usually the left column contains checkboxes for multi-select operations. The second column contains filenames, web page names, survey names etc. The remaining columns usually contain information on the item in the second column and sometimes links or buttons that can be used to operate on the item such as Edit or Delete. If this type of table is coded with the correct row and column designated as headers the table is easily used and accessible. This example is an occasion where the column header is not the left-most column so the assistive technology would guess incorrectly if the header is not explicitly defined.
These are a few usability considerations for web-based application interfaces. In general terms it is much easier for the user with a disability to use the web-based application if the features and controls for the application are similar to standard HTML controls. In some cases the look and feel of the application might change since fancy widgets might not be easily implemented. On the other hand the point of having the application is for it to be used and useful.