UX

All posts tagged UX

Setting Up an Accessible Web Page: The Footer (A UX Accessibility Blog Post)

Posted by kayladsween on June 29, 2017

Posted in: Usability. Tagged: Accessibility, inclusive design, User Experience, UX. Leave a comment

This UX Accessibility Blog Series, “Setting Up An Accessible Web Page,” will walk you through the basic elements of an accessible web page in hopes that you can take what you’ve learned and apply it to more complex pages. This blog series is loosely based on Heydon Pickering’s book “Inclusive Design Patterns: Coding Accessibility Into Web Design.”

Page footers give the user additional information, usually about the company, such as copyright information, privacy statements, and terms of use. The footer of the page is denoted in <footer> tags in HTML5. According to the HTML5 specification, <footer> carries the implicit role of contentinfo as long as it isn’t a descendent of an <article> or <section> element. However, it is important to explicitly add the role=”contentinfo” attribute because Internet Explorer does not fully support it. This may seem redundant, but it is the best practice to do this until all browsers fully support HTML5 and its accessibility features.

div>

 //or 
    
        
            
                
                    Copyright © FNC, Inc. All rights reserved.
                    http://www.fncinc.com/legal.aspx', 'FNCLegal', 'status=no,toolbar=no,location=no,menu=no,scrollbars=yes,screenX=0,screenY=0,width=792,height=567');">Privacy Statement
                    User Agreement
                    Rules & Regulations
                
            
            
                http://www.fncinc.com" target="_blank" class="img-fnc-logo" title="FNC, Inc homepage">
            
        </div>
    </div>
</div> //or </footer>

The WAI-ARIA documentation describes the contentinfo role as “a large perceivable region that contains information about the parent document.” It goes on to say that any element with the role contentinfo should be treated as a navigational landmark and contentinfo should not appear more than one time on each page.

According to Bruce Lawson in his article “Why does HTML footer take role=”contentinfo”?”, contentinfo is a better semantic name for the information area that we call the “footer”. This could be why those who wrote the ARIA standards used contentinfo rather than footer. Web developers, however, have been using the class “.footer” for years in their mark-up. Therefore, the HTML5 specification accommodated for those who have been writing this way.

As previously mentioned in the “Accessible Images” blog post, make sure the logo in your footer has the correct alt text. The footer logo is typically an image link, so the alt text needs to tell the user where the link points to. In this case, the logo’s alt text should say something like “FNC, Inc Homepage”.

Setting Up an Accessible Web Page: Filtering Data (A UX Accessibility Blog Post)

Posted by kayladsween on June 29, 2017

Posted in: Usability. Tagged: Accessibility, inclusive design, User Experience, UX. Leave a comment

Filtering data is a great way to give users control of the information they want to see. This helps many different types of users all at once. Sighted users have the ability to narrow down a page of data results from, for instance, 2000 results to 200 results, making it much easier to find the specific content they are looking for. Visually impaired users use filters for the same reason. Having a screen reader read out 2000 results with no way to filter can be extremely cumbersome.

It is also important to give users multiple ways to filter through. Giving users this extra mechanism over what they’re able to see helps them have a sense of control over the information they are consuming.

Waiting Spinner

Anytime the user is waiting on data to load, there needs to be a waiting spinner. Waiting spinners are a great, simple way of showing sighted users that there will be information displayed momentarily. However, screen reader users are at a disadvantage. They’re typically left in the dark on the status of their action or if it went through at all. Make sure that you use WAI-ARIA’s live regions to tell the screen reader user that everything is fine and the data will be available soon.

To make this truly inclusive, make sure the screen reader announces both when the content is loading and when it is done. For example:

<span class=”sr-only” aria-live=”assertive”>Please wait. Populating table.</span>

<span class=”sr-only” aria-live=”assertive”>Data population complete.</span>

Another helpful addition could be to add a statement with the number of entries loaded at the end of your “Data population complete.” statement.

aria-live

The aria-live attribute is used to set the priority of the live region for screen readers. aria-live can be set to off, polite, or assertive. The polite value tells the screen reader to wait until it has finished reading the rest of the page before coming back to the section that has updated. Usually, aria-live=”polite” is the best option since it reduces the chance that you’ll startle or confuse the user by interrupting the screen reader. The assertive value interrupts the screen reader’s set script of the page to alert the user to a change. When using aria-live with a waiting spinner, it is best to use the assertive value since it will immediately alert the user to the change.

To maximize browser compatibility, some accessibility experts recommend using both aria-live=”assertive” and role=”alert”. This can be problematic, according to the Mozilla Developer Network’s “ARIA Live Regions” article, as it can cause double speaking issues for VoiceOver in iOS.

Setting Up an Accessible Web Page: Making Tables Accessible (A UX Accessibility Blog Post)

Posted by kayladsween on June 27, 2017

Posted in: Usability. Tagged: Accessibility, inclusive design, User Experience, UX. Leave a comment

Tables that have specified rows or columns with header information about that particular row or column is considered a data table. Without a header, a table can be considered a formatting table. Personally, I don’t like to use tables to format content, but it’s not technically wrong. In this blog post, I’ll be focusing on making data tables accessible.

General

The simpler the table, the better. Simple tables are more easily understood than ones that are more complex (i.e. have multiple table headers or sections). Simpler is always better, but necessity will dictate how simple your data tables can be. However, it is recommended that you do your best to simplify your data tables as much as possible to be understood by a broader audience.

TH and the scope attribute

Sighted users have the luxury of being able to read data tables in any orientation the data may be displayed in. Screen reader users can only hear one cell at a time from left to right, top to bottom. This can easily cause confusion, especially if the table is complex or doesn’t use the right attributes in the markup to make it accessible.

Table headings allow sighted users to designate certain table cells as headers for the column or row it belongs to.

The scope attribute is used to clarify the scope of a header cell and aid comprehension for those who use screen readers. It identifies whether the cell is a header for a row, column, group of columns, or group of rows. The scope attribute can also be used on <td> tags to denote the content of the cell is the header for a row. For example:

<table class="table table-bordered col-2-bloat">
    <thead>
        <tr>
            <th scope="col">#</th>
            <th scope="col">Address</th>
            <th scope="col">GLA</th>
            <th scope="col">Sales Price</th>
            <th scope="col">MLS Number</th>
            <th scope="col">Service</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>1</td>
            <td scope="row">123 Main St</td>
            <td>0001</td>
            <td>$1,500,000</td>
            <td>q11111</td>
            <td>Desktop Appraisal</td>
        </tr>
        <tr>
            <td>2</td>
            <td scope="row">100 North St</td>
            <td>3205</td>
            <td>$580,000</td>
            <td>z00111</td>
            <td>Desktop Appraisal</td>
        </tr>
    </tbody>
</table>

Sometimes the scope may not need to be on the first element of the row. As in the example above, it would aid comprehension for the screen reader to read out the street address before every value rather than the number row it is.

Penn State’s Accessibility article titled “Tables for Data in HTML” has a great example for how table headings can aid comprehension of a visually impaired user.

Assuming the markup is correct and uses scope as we showed in the code example above, the screen reader should read out the following:

“black, Spanish: negro

black, French: noir

black, Irish: dubh

black, Welsh: du…”

This way, by the time the screen reader reads the last element of the row, the user is still able to remember what English term is being translated.

Setting Up an Accessible Web Page: Making Forms Accessible (A UX Accessibility Blog Post)

Posted by kayladsween on June 22, 2017

Posted in: Usability. Tagged: Accessibility, form elements, inclusive design, User Experience, UX. Leave a comment

We’ve talked about what needs to be done to make forms accessible multiple times before, but since the relationship between these elements and accessibility/inclusivity is an important conversation to have, we’ll go over them (maybe in a bit more detail) again.

Labels and Inputs

Labels are used to identify all types of inputs and other form controls (such as <select>s or <textarea>s). Browsers allow the labels to become part of the clickable area that can be used to allow the input to receive focus. Labels also insure that assistive technologies correctly associate the label with the corresponding input field. For this reason, you should never use placeholders in the place of a label.

To associate a label with an input field, just set the for attribute in the label element to the id of the input it corresponds with. For example:

<label for=”firstName”>First Name:</label>
<input type=”text” name=”firstNameTextbox” id=”firstName” />
<label for=”pizza”>Pizza Type:</label>
<select id=”pizza” name=”pizzaSelect”>
    <optgroup label=”Veggie Friendly”>
        <option value=”1”>Cheese</option>
        <option value=”3”>Veggie</option>
    </optgroup>
    <optgroup label=”Meaty Pizzas”>
        <option value=”2”>Pepperoni</option>
        <option value=”4”>Sausage</option>
    </optgroup>
</select>

Text inputs can have an attribute called placeholder that you can use to give your users an example of what they should type in the input field. Never use the placeholder attribute instead of a label for the field. Using the placeholder attribute as the text input label can cause the user confusion since the placeholder disappears as soon as the user starts typing or as soon as the field receives focus.

Radio Buttons and Checkboxes

The best way to make radio buttons and checkboxes accessible is to use the <fieldset> and <legend> tags. The fieldset tag surrounds the group of radio buttons or checkboxes to show that those are the options for this particular group. The legend tag gives the fieldset a name to show the user what they’re picking. Screen readers repeat the legend text for each option in the fieldset, so it is important to keep your legend text as concise as possible.

<fieldset>
    <legend>Pizza Type</legend>
    <input id=”cheese” type=”radio” name=”pizza” value=”cheese” /><label for=”cheese”>Cheese</label>
    <input id=”veggie” type=”radio” name=”pizza” value=”veggie” /><label for=”veggie”>Veggie</label>
    <input id=”pepperoni” type=”radio” name=”pizza” value=”pepperoni” /><label for=”pepperoni”>Pepperoni</label>
    <input id=”sausage” type=”radio” name=”pizza” value=”sausage” /><label for=”sausage”>Sausage</label>
</fieldset>

There’s no point in using a fieldset without a legend, so always make sure the checkboxes or radio button groups warrant needing a legend. Sometimes the meaning of the group can be determined by the labels of the inputs alone, for example, radio buttons that say “male” or “female” or a single checkbox that says “I agree to these terms” or “is billable”. In this case, a fieldset and legend shouldn’t be used because the purpose is clear and addition of a legend could just confuse the user.

The American Foundation for the Blind also suggests that you could include the fieldset into the label of the first option. This may be accessible, but requires the developer to add breakpoints (<br>) between what should be the legend and the first option’s label. <br> tags are hard to standardize across devices and browsers and are not semantic. Therefore, this option should not be used.

Setting Up an Accessible Web Page: Making Buttons Accessible (A UX Accessibility Blog Post)

Posted by kayladsween on June 22, 2017

Posted in: Usability. Tagged: Accessibility, Bootstrap, buttons, HTML, inclusive design, Twitter Bootstrap, User Experience, UX. Leave a comment

We’ve talked about what needs to be done to make buttons accessible multiple times before, but since the relationship between these elements and accessibility/inclusivity is an important conversation to have, we’ll go over them again.

General Button Accessibility Tips

As always, using semantic HTML is always preferable when it comes to accessibility. Most browsers know how to accessibly deal with semantic mark-up by default. Native HTML buttons (<button>, <input type=”button” />, <input type=”submit” />, <input type=”reset” />) also support keyboard and focus requirements without needing any other customization, according to Mozilla Developer Network’s “Using the button role.”

Button tags must never be left empty. If your button contains only a glyphicon, make sure you make the glyphicon button accessible by adding a <span class=”sr-only”>[Action glyphicon represents]</span> after your glyphicon or add a title attribute to the button itself describing the action the user can expect to happen. Assistive technologies can’t read glyphicons, so they will understand the button as empty. This is why if you run WAVE or a similar accessibility checker on a page that has a glyphicon button, it may display an error stating the button is empty.

Colors

Color can be used in a way that quickly and efficiently tells the user what a button is used for. It is best if the color of the buttons follow convention, as shown in Ensemble. Our users are acclimated (especially those that use our newer systems) to the three main button colors, blue, black, and grey. Each color corresponds with a particular type of action. For submit buttons, we typically use blue (.btn-primary) buttons. Our users, and most other users, associate this with an action like submitting, saving, etc. For delete buttons, we use black (.btn-inverse) buttons. For any action that doesn’t submit, save, or delete, we use grey (.btn-default) buttons. The grey buttons are typically for cancelling an action, resetting a form, etc. These colors are to be used in conjunction to a description, not in place of. Color alone should never convey meaning.

Buttons as Links

If you have an anchor tag that is styled like a button and redirects to another page, do not add the role=”button” attribute. Adding role=”button” will confuse your users since they are expecting an action to take place on that page.

Occasionally, modals won’t trigger correctly if you use a <button> element. In this case, it’s necessary to use <a href=”javascript:void(0)” role=”button” class=”btn btn-default”>Button</a>. In this example, using role=”button” is good since it triggers an event on the page and doesn’t redirect the user to a different page. As Bootstrap framework developers work to make elements more accessible, this may change. But for now, the downside to this is semantics. Assistive technologies will see the anchor tag as a link before they’ll see it as a button, therefore it’s ALWAYS better to use semantic HTML for buttons if possible.

Setting Up an Accessible Web Page: Making Images Accessible (A UX Accessibility Blog Post)

Posted by kayladsween on June 20, 2017

Posted in: Usability. Tagged: Accessibility, Accessible Images, img, inclusive design, User Experience, UX. Leave a comment

We’ve talked about what needs to be done to make images accessible multiple times before, but since the relationship between these elements and accessibility/inclusivity is an important conversation to have, we’ll go over them (maybe in a bit more detail) again.

Why?

As we’ve discussed in a previous blog post, images can help users comprehend what they are reading better by giving them something visual to associate with the text. For example, if you’re looking at houses to buy on Zillow, the pictures can help you decide if you are interested in the house even more than the text description alone of the house.

Visually impaired users do not have this luxury. They rely on only the text descriptions of pictures to help them gain a better understanding of what the images on a page are. Text alternatives are read by screen readers to the user in place of the image. Also, in the event that your user has a slow internet connection (out in the field, internet outage, etc.), the images on your page may not load at all, causing the alt text to be displayed in place of the images themselves. Adding alt text to your images also satisfies the first principle of web accessibility, perceivable. For these reasons, it is imperative that clear, descriptive alternative text be added to every image.

Every image should have an alt attribute. (bolded, italicized, and underlined because it’s just that important)

Links

If your image also happens to be a link, make sure the alt text describes the link destination and not necessarily the image itself. For example, you have the FNC, Inc. logo on your page that links to fncinc.com, such as in your footer.

In this case, using “FNC, Inc. Logo” may not be very helpful. You’ll need to make sure the alt text says something like, “FNC, Inc Home Page”. According to Penn State’s accessibility article, “Image ALT Tag Tips for HTML,” providing a full description (saying “FNC, Inc. Logo. Directs to FNC home page”) is unnecessarily redundant.

Purely Decorative Images

Images that are used for purely decorative purposes, such as a horizontal line that separates two sections, don’t necessarily need a description. Penn State’s article uses a rainbow divider image as an example.

Screen reader says “A rainbow line as a divider.” If you have eighteen rainbow toolbars, the screen reader would repeat this eighteen times. This text is irrelevant to a screen reader user and increases reading time.

In this case, adding the description in the alt attribute could just annoy the user. However, every image must have an alt attribute, so we can add the alt attribute, but leave it equal to an empty string. This satisfies the HTML requirement of having an alt attribute but also keeps screen readers from just announcing “image” when encountering an <img /> tag that doesn’t have an alt attribute.

Again, every image must have an alt attribute.

Setting Up an Accessible Web Page: When and How to Use a Menu Hamburger (A UX Accessibility Blog Post)

Posted by kayladsween on June 20, 2017

Posted in: Usability. Tagged: Accessibility, Conventions, inclusive design, Menus, Navigation, User Experience, UX. Leave a comment

Sometimes, to save screen real estate, it is necessary to use a menu icon to denote that the navigation region can be toggled into view. This is very common on small interfaces, such as smart phone screens. Using the hamburger icon to denote a collapsible menu has become convention for showing that menu options can be shown or hidden.

Why do we need an icon at all? Specifically, why the hamburger menu icon (glyphicon-menu-hamburger)?

It’s been long established that images help sighted users comprehend the meaning of certain functions faster than text alone. This is especially helpful when your target audience consists of users that could speak different languages or have poor reading ability. However, this doesn’t mean that we should remove text all together and only use icons to denote meaning. Newer internet users may not understand the meaning of a glyphicon, but they can read the word “menu” next to the icon and understand from then on that icon means “menu”.

The hamburger icon represents a list. As discussed in the “Site Navigation” blog post, navigation sections are conventionally denoted by using an unordered list. The three horizontal lines of the hamburger icon are used to represent a list. Assuming your navigation mimics a list, this greatly assists the inclusivity of your web page by following convention. As Heydon Pickering says in Inclusive Design Patterns: Coding Accessibility Into Web Design, “convention is a friend to inclusion.”

Glyphicons vs SVG

In his book, Pickering recommends using SVG to render icons. SVG stands for Scalable Vector Graphics and, according to Wikipedia, is an XML-based vector image format for 2D graphics that supports interactivity and animation. SVG images and the behaviors associated with them are defined in XML text files, which means they can be searched, indexed, scripted, and compressed. This can be extremely helpful when it comes to accessibility. SVGs also have the ability to change with the text color. Therefore, if a user has their browser set to invert colors, the SVG will change colors just like the text.

However, SVGs can be a bit more complicated than just using glyphicons, especially since glyphicons come standard in Bootstrap and Ensemble. Since glyphicons are a text font, they tend to behave like text. When the user resizes the screen or inverts the colors of their browser, the glyphicon will react to these changes just as text would. The only downside to using icon fonts is that some users may choose a different font that doesn’t play nicely with glyphicons, such as users have dyslexia and change fonts to reduce the difficulty of reading.

Communicating State

When using a menu hamburger to show that your navigation region is collapsible, it is important to use the aria-expanded attribute to allow assistive technologies to communicate the state (collapsed or expanded) to the user. If your menu is collapsed by default, add aria-expanded=”false” to your menu button. Make sure that the value of the aria-expanded attribute toggles between true and false depending on if the menu is expanded or collapsed.

Conclusion

When considering against using a menu hamburger or any other convention for an element, consider the implications on your users. Especially in the case of collapsible menus, it’s important to follow convention and communicate the menu’s state to maximize the odds that your users will understand exactly what you’re trying to convey.

UX

All posts tagged UX

Setting Up an Accessible Web Page: The Footer (A UX Accessibility Blog Post)

Setting Up an Accessible Web Page: Filtering Data (A UX Accessibility Blog Post)

Waiting Spinner

aria-live

Setting Up an Accessible Web Page: Making Tables Accessible (A UX Accessibility Blog Post)

General

TH and the scope attribute

Setting Up an Accessible Web Page: Making Forms Accessible (A UX Accessibility Blog Post)

Labels and Inputs

Radio Buttons and Checkboxes

Setting Up an Accessible Web Page: Making Buttons Accessible (A UX Accessibility Blog Post)

General Button Accessibility Tips

Colors

Buttons as Links

Setting Up an Accessible Web Page: Making Images Accessible (A UX Accessibility Blog Post)

Why?

Links

Purely Decorative Images

Setting Up an Accessible Web Page: When and How to Use a Menu Hamburger (A UX Accessibility Blog Post)

Why do we need an icon at all? Specifically, why the hamburger menu icon (glyphicon-menu-hamburger)?

Glyphicons vs SVG

Communicating State

Conclusion

Archives

Authors

What’s Unwound

Setting Up an Accessible Web Page: The Footer (A UX Accessibility Blog Post)

Setting Up an Accessible Web Page: Filtering Data (A UX Accessibility Blog Post)

Waiting Spinner

aria-live

Setting Up an Accessible Web Page: Making Tables Accessible (A UX Accessibility Blog Post)

General

TH and the scope attribute

Setting Up an Accessible Web Page: Making Forms Accessible (A UX Accessibility Blog Post)

Labels and Inputs

Radio Buttons and Checkboxes

Setting Up an Accessible Web Page: Making Buttons Accessible (A UX Accessibility Blog Post)

General Button Accessibility Tips

Colors

Buttons as Links

Setting Up an Accessible Web Page: Making Images Accessible (A UX Accessibility Blog Post)

Why?

Links

Purely Decorative Images

Setting Up an Accessible Web Page: When and How to Use a Menu Hamburger (A UX Accessibility Blog Post)

Why do we need an icon at all? Specifically, why the hamburger menu icon (glyphicon-menu-hamburger)?

Glyphicons vs SVG

Communicating State

Conclusion

Archives

Authors

What We're Working On

What’s Unwound