When designing a dashboard, you’re usually thinking about things like which parameters are required, the type of information your users want to see, and how you can lay everything out on the form so that it makes sense. What you might not have thought about is how you can make your content easier to use for people with certain types of disabilities. For example, some users rely on assistive technology such as a screen reader or screen magnification tool in order to see the content. Others may require the use of a keyboard or other input device instead of a mouse. And a significant percentage of users can benefit from using text that stands out well and is visible to people with colorblindness.

Up to 8% of the population has some degree of colorblindness, which is a significant portion of the people who may be using your DataBlocks. Basically, even if accessibility is not required by your institution (and it often is), what it comes down to is that if you want people to be able to use your content, you need to make it accessible.

In this post, we’ll be discussing some best practices and techniques that can be leveraged within Argos to design dashboards that are easier to use for people with disabilities. The information on accessibility design principles is based off of the WCAG 2.0 level A and AA guidelines, located at https://www.w3.org/TR/WCAG20/.

Form Layout

Most screen readers read documents linearly, from top to bottom, left to right. If you keep this in mind, you can group logical information so that it will be read in an intelligent order, rather than relying on the visual presentation to convey meaning. For example:

  • Place a descriptive title or heading at the top of your forms, and at the top of any logical sections so that users know what they are looking at.
  • Consider placing labels above or to the left of objects, instead of underneath or to the right. The Labeled By property discussed later in this post can also help with this for certain object types.
  • Buttons that perform actions based on entered parameters should appear after the parameter fields, not above them. This allows users to enter parameters and then tab to the button, instead of forcing them to jump back to the top of the page to proceed. You may also use the Tab Order property to control the navigation where a button in a different location is required.
  • If you have objects grouped together on a panel, ensure that the tab order for those objects makes sense and does not send the user back and forth between different, unrelated areas.

Button and Link Text

Screen reader users may not be able to understand the purpose of a button or link when it is taken out of context of the visual presentation or surrounding text. When tabbing to a button or link, any previous text content is skipped. A good solution for this is to use descriptive text for the button or link. For example, instead of labeling your button “Go”, you might call it “Retrieve Data.” For a hyperlink, this could say “Launch Google” instead of “click here.”

Choice of Objects

Use the correct type of dashboard object for your intended purpose whenever possible. For example, if you want a button, use a button object instead of a shape with a label on it. Buttons are keyboard-accessible by default (the Tab Stop property is automatically set to Yes for you), whereas shapes and labels are not.

Color and Contrast

For normal sized text, you should choose appropriate colors that have a contrast ratio of at least 4.5:1 with the background color. Large-scale text (generally considered 18 point or higher) can have a contrast ratio of 3:1. There are many free contrast checking programs available, such as Colour Contrast Analyser, that make it very easy to select foreground and background colors and verify that they have sufficient contrast. Some of these programs will also show you what your color selections look like to people with varying types of colorblindness.

One thing to keep in mind is that you should not rely on color as the sole means of conveying information. For example, if you are using colored icons to indicate the status of something, make sure that the icons also have text on them or have different shapes or some other way for users to differentiate their meanings.

Object Properties Affecting Accessibility

Most Argos objects have properties than can be used to improve accessibility. Where provided, you should use these properties to ensure the best experience possible for your users. Please note that the Accessible Text and Labeled By properties discussed below were added in Argos version 5.4, so if you’re on an earlier version you may want to talk to your MAPS administrator about upgrading!

Accessible Text

Some form objects have an Accessible Text property, which can be used to provide a text alternative to objects that contain visual information, such as images, charts, OLAP cubes, and shapes. It also works with edit boxes and list/multi-column list boxes. When a screen reader user navigates the dashboard in the Web Viewer, this text is read to the user, helping them to identify the content if they are unable to see it.

This property is currently only supported in the Web Viewer, and does not have any effect when using a screen reader in the Argos client (may be added in a future release). As a best practice, you should always fill this field out where it makes sense to do so. This ensures the best possible experience for users who rely on assistive technology to navigate Argos.

Labeled By

The Labeled By property is a drop-down field that allows you to choose an existing text object on the dashboard to assign as the label for this object. When using a screen reader in the Web Viewer, the selected text label will be read to the user when they navigate to the object. When designing a DataBlock with accessibility in mind, it is a best practice to assign labels for all form input fields, particularly edit boxes, date edits, and drop-down controls. This property can also be used with checkbox and radio button groups, list and multi-column list boxes (note: does not work with list boxes using JAWS/IE), and memo fields.

In the example above, the variable name of the label with text “Select a letter” label is Label1Letter. To associate it with the dropdown that the label is describing, select the dropdown field and then set the Labeled By property to the variable Label1Letter.

Note: Most edit boxes should use the Labeled By property to associate the edit box with its visible label. In the case of edit boxes that do not have a text label, or that require more specific information than the label includes in order to communicate something that is obvious visually, you can use Accessible Text to provide this. A good example is a set of two fields intended for entering different lines of an address. A sighted user can see that the “Address” text label belongs to both fields, but a screen reader user would benefit from having a label on each field since they are unable to see the grouping visually.

This property is currently only supported in the Web Viewer, and does not have any effect when using a screen reader in the Argos client (may be added in a future release).

Tab Stop

The Tab Stop property is what allows users to navigate to that object using the keyboard. It should be set to Yes for objects that users should be able to interact with, such as form fields, buttons, and list boxes. If Tab Stop has been set to No for an interactive object, keyboard users may be unable to access it, potentially preventing them from using your DataBlock.

Tab Order

The Tab Order property controls the navigation order when using the keyboard to tab through dashboard objects. The tab order should ideally match the visual tab order on the screen, and should make sense to the user when hearing the fields in sequence. The default tab order is the order that fields were added to the dashboard, so you may need to adjust this as you add, remove, or reposition form elements. Argos will attempt to intelligently adjust the tab order of other objects if you specify a number that is already in use.

Conclusion

Accessibility doesn’t have to be a lot of work. If you understand the basic principles and know what tools are available to you, it’s fairly straightforward to design content with the goal of making it as accessible as possible. Not only will this significantly help some of your users, but designing for accessibility can also improve your dashboards for everyone else, since you will be creating well-organized layouts that are easy on the eyes and simple to use. Particularly when entering parameters, your users will very much appreciate being able to fill out all of the required information without taking their hands off the keyboard.

Keep an eye out from us for further updates on this topic. Evisions is working on additional accessibility-related enhancements that will appear in future versions of Argos. To be notified when new features are available, you can subscribe to updates for specific products on our forums. And as always, if you have any questions, comments, or feedback on these features or would like to see a specific feature added or prioritized, please let us know.

Like this blog?

You might also like this eBook:

Alwyn Durham

Alwyn Durham is the Senior Technical Writer for Evisions. He graduated from UC Irvine with a degree in Computer Science in 2004. After spending several years doing freelance web development while bicycle touring in Europe, he moved back to the US and joined Evisions in 2009. Alwyn has a particular interest in product accessibility and has led Evisions' accessibility initiative to work toward full Section 508 and WCAG 2.0 compliance. In between maintaining product documentation and Evisions' online help, he is currently pursuing a certificate in full-stack web development in order to better assist with the necessary accessibility improvements to Evisions' web-based software.

Latest posts by Alwyn Durham (see all)

Share This
X