Sign up to newsletter


 

    UX resources

    BUILDING BEST USER EXPIRIENCE

    User Experience resources and information.

    Accessible Interface Design, Part 2

    Tips and Techniques for Accessible Web Applications

    by Mark McKay

    Alt &Title Tags. Always Use Them.

    Alt &Title attributes are key tools for creating more accessible web applications. We can use them to label icons or other form controls to make them understandable by disabled users.

    Use both the alt and title attributes as some browsers will show one but not the other. Make your text as descriptive as possible; don’t use ‘Delete’ instead use ‘Delete <filename>’.

    Don’t put links in your labels as they could make it impossible for a user to click the label text for a control to activate it. Instead use an icon to launch an accessible pop-up window or other inline help text system.

    All Form Controls Need Labels

    Every form control, except buttons, needs label tags. This is how you would mark up a label for a First Name field in a contact form: <label for=”firstName”>First Name</label> <input id=”firstName” type=”input” />. This way a user can click the label text to activate the control. This is very important for check boxes and radio buttons because users with mobility impairments can have a hard time clicking these small controls. One tip you can use to make sure your developers have coded your labels properly is to click them. If the code has been done correctly, the control that the label belongs to should become active. I often use this technique when performing testing on sites I am working on.

    Include Required Indicators and Help Text in Your Label Tags

    By doing this you ensure that a screen reader user knows which fields are mandatory.

     

    If you provide help text about how to fill in a field, place this text in the label tag too so that the screen reader users will be aware of it.

     

    Also make sure that if you note that * denotes a required field place it at the top of your forms not the bottom. Screen readers, and everyone else for that matter, need to have a chance to be aware of it first.

    Title Tags

    All title tags, for example <title>Sign in to Spokentext</title>, should be unique for each page. This information is used by screen reader users to determine which page they are on and get context. It is also a good idea to do this for search engine optimization reasons and general usability reasons as your title tags become the text used for bookmarking a page.

    Avoid Using Fixed Fonts

    Internet Explorer will not allow users to scale the fonts on your site if you define your fonts in pixel values. Always define them in percentage (%) or (em). Both definitions allow your users to scale the font on your applications.

    Plain Language

    Of all the tips in this article, this has been the hardest one for me to convince my clients to do. Most of them think that the language they speak and write in is simple, plain language. But it is not. I have worked on projects where we have writers who are experts in plain language write our content just to have the client change it at the last minute, adding back in all of the industry specific language (in my case government language). And thus making the site harder to use.

    A lot of my clients also take it personally when you comment about their content. They feel it is their job to write the content when it is usually their job to make sure the message in the content is correct.

    All that said, plain language writing is critically important for the cognitively impaired and persons with low literacy skills. Do your best to make sure the text in your application is written in plain language no matter who’s ego you have to step on or stroke.

    Document Structure – Semantic Code and Validation

    For example, use <h1> Welcome </h1> not <strong> Welcome </strong> for headings. This seems so simple but people still don’t do it. If an interface uses headings correctly screen reader users can then navigate by heading thereby greatly speeding up their interaction with your site.

    There is more to this than just headings. Use tables only for tabular data and if a section of content is a list then use list markup to display it. All of this helps assistive technologies provide context to the information within your pages. For example, JAWS will say things like “list of 10 items” or “table with 4 rows and 3 columns”. Both help users to create mental models of how your site works and what a page contains.

    Overall, validation is important as proper code is easier to parse and interpret for assistive technologies.

    Progressive Enhancement, AJAX and Hijax

    Progressive enhancement is one of the best concepts to come out in a long time. We build our interfaces to work at a core level for everyone and then layer on other features for users who can take advantage of them.

    As an example, in SpokenText I needed a way to inform members as to the status of their recordings. I created a page called “View Recordings” which listed all of the user’s recordings and had a Status column that let the user know at what stage in the process was the recording. To update the status of the recording the user could click the “Update Status” button. The page would then reload and the status would update. This is a simple, accessible solution, but not ideal for users without disabilities who could see content change automatically on a page. What I did was to write a small piece of AJAX code to automatically update just the rows which have changed without the user having to click any buttons thus improving the site’s experience without hurting the experience of users to whom this feature would be of no use.

    We have to remember that we need to include disable people’s needs in our design but at the same time we don’t want to make our non-disabled users experience less than optimal. This is the design challenge that makes good accessible design so much fun to work on as an Interaction designer.

    No JavaScript onChange Events

    The issue with using a JavaScript onChange event to trigger an action is that a person trying to use your interface with a keyboard can’t move up and down the list of items in a select list. Once they hit the down arrow the onChange event executes and they are moved to a new page or whatever is scripted to the event.

    Don’t Reload/Refresh/Redirect Pages Automatically

    The issue with reloading or redirecting users automatically revolves around control and choice. It can take some users longer then others to understand what to do on a page and take action. If the page does not allow them to determine what to do next they will have lost all control over their interaction with the site.

    Hidden Labels

    Sometimes you need to create grids of fields. Like the following.

     

    This is a good place to use hidden <label> tags. The <label> for A would be <label for=”a”>Calls Per Day from 9am to 5pm</label> and the label for B would be <label for=”b”>Minutes Per Call from 9am to 5pm</label>. The rest of the labels would just follow this pattern.

    Here is the CSS code to hide the labels:

    /* Hide labels when there is no room to display them */
    .hideLabels {
    position:absolute;
    left:0px;
    top:-500px;
    width:1px;
    height:1px;
    overflow:hidden;
    }

    Meaningful Link Text

    Different user agents (like JAWS) allow users to view a list of links on a page. If you have ten links called ‘edit’ or ‘more’ the user would have no idea which link will perform which action.

    For this reason use descriptive link text, or in some cases you can use hidden link text, to add the extra information you need to make the link meaningful while hiding this extra text from users who don’t need it. Hiding link text should be a last resort. Whenever possible avoid it as you never know how well it will work with all of the different accessible technology available today.

    Hidden Link Text

    Sometimes you want to use links within a list of data for users to click on. But the issue is that you will have the same link text repeated many times throughout the page. This breaks the rule about links being meaningful when taken out of context. To solve this we can use hidden link text which is only read by screen readers.

     

    Here is the CSS code to hide the extra text:

    /* Hide link text */
    span.hideSpan{
    position:absolute;
    left:0px;
    top:-500px;
    width:1px;
    height:1px;
    overflow:hidden;
    }

    Using Icons for Actions

    This is a very common approach I use to solve the problem of deleting items in a list. By using an image I can give it a very meaningful title and alt text . In the example below, the alt and title attributes for the delete icon will be “Delete Benjamin Graham The Intelligent Investor”. This way a screen reader user knows exactly what will happen when they click this icon. Make your icons as large as possible, at least 16px by 16px or bigger. And, if you can, extend the hit area for your icons using CSS.

     

    Don’t Use Access Keys

    Access keys were an interesting idea. But the issue is that access keys can conflict with the shortcut keys used by a user’s adaptive technology. For users of tools like Jaws, their whole interaction with a computer is driven by utilizing Jaws shortcut keys. In your design, you might think that you are doing disabled people a favour by putting access keys into your web application but in the end you might be making their experience worse.

    Don’t Modify the Natural Tab Flow

    By using tabindex=”x” you can control the order of how users will be moved from field to field on your page. The issue with this is that, to a user of a screen reader, this can make it hard for them to form a mental model of the whole form on the page and how one field relates to another. A well designed form should have a default tab order that makes sense to all users. So don’t use tabindex to specify the taborder as you could be potentially making your site harder to use by disabled people. This can also make future maintenance harder if you want to add a new field in a page because you will need to update all of the existing controls tab indexes. A very tedious and error prone task. I have seen applications where the tab order is all over the place because someone thought it would be a good idea to add tab indexes to each control.

    Keep Legends Short

    When a screen reader user using JAWS, for example, is in “forms mode” all legends are read to him or her before the label text for a form input is read. So you can imagine how frustrating it would be to have to listen to a long sentence as you try to figure out which item you wanted to select in a radio group. Keep fieldsets to under six words to avoid this.

    This example comes from an administration interface I worked on. It is nice and short. Using a screen reader is a slow way to interact with a computer. We have to make sure we do our part to use as little text as possible so that we do not waste screen reader users’ time.

    Using Legends example

    Deleting Items From a List

    Check boxes are small targets to click so we need to make sure that we always have labels for them. The user can click the label to activate the check box.

    Below is a screen shot from SpokenText.net where I used the recording name as the label for each check box. This way the user can figure out which check box relates to which row in the table. This is a very common pattern but it is surprising how many times people don’t follow it. If I needed more information to make the label clearer I would think about using some hidden text within the label tag.

     

    Avoid Using Multi-Column Layouts for Forms

    Forms which are laid out horizontally can be hard to use by people with screen magnifiers since they might never scroll right to see the second part of the form. Most forms are laid out in one column or two columns with the fields in one column and the form controls in the other. Both of these two options work best for screen magnifier users.

    Error Messaging

    Whenever possible use large error boxes that stick out from surrounding content and offer good contrast. They should be at the top of forms so that a screen reader user is able to read them before traveling to the field which needs attention.

     

    Simple and Elegant Design is Best

    Keeping it simple is very easy to say but is hard to do with all of the issues we face when designing applications. From clients to marketing departments everyone is trying to cram their features or opinions into an application’s design.

    But it still holds true, for me, that the simpler an application is to understand it will be generally more accessible if the basic rules regarding accessibility have been followed.

    So strive to keep it simple and to borrow a phrase from a great book “Don’t make users have to think”

    The Future of Accessible Web Applications

    Accessible Rich Internet Applications (ARIA ) looks very promising. With it we will gain concepts like roles and live regions, some of which are in Firefox now. Firefox’s implementation of ARIA allows desktop-style widgets such as tree views, menu bars and spreadsheets. These are accessible both with the keyboard and assistive technologies such as screen readers, screen magnifiers and alternative input devices. It also helps provide accessibility solutions for AJAX-style live updates to regions on a page. Few access technologies support ARIA at the moment but will in time.

    AxsAJAX, Google’s foray into this area is also interesting. You can check it out at http://code.google.com/p/google-axsjax/

    Operating Systems and Accessibility

    At the moment the Windows platform is still the most accessible operating system when you use it along with specialized access technology for the disabled. Out of the box, Apple’s OS X is the best. Mac includes a superb screen magnifier and screen reader which are great for free but not as good as the software you can buy for Windows. I have played with Linux’s accessibility and it is coming along but is still years behind Windows and OS X.

    Development Platforms

    As you might guess from the previous section, Windows development platforms are still the best for creating accessible desktop and thick clients. You can make Java applications accessible but users of tools like JAWS will have to install extra software to get your application to work for them.

    I mention this because if you have the ability to pick which tools you use to develop your software you might want to consider using a development platform which is accessible to the largest number of people possible.

    Conclusion

    It is true that well designed, properly coded, visually appealing applications can be even more accessible when they use proper structure, plain language, headings and label interface controls in a meaningful way. I challenge everyone reading this article to make your next application beautiful, usable and accessible.

    About Rose-team

    We are small website (new born in September 2016) which would like to contribute to UX world by being a information base for all UX designers.

    We will try to gather a wide range of usefull information from touching different areas of User Experience design.

    Please feel free to send us all type of materials  we will be happy to publish them.

    Thanks!