HTML

All posts tagged HTML

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: , , , , , , , . 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.”

 

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.

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: The Paragraph (A UX Accessibility Blog Post)

Posted by kayladsween on March 7, 2017
Posted in: Usability. Tagged: , , , . 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.”

Readability is Important

It’s important for all of your content to be easy to read and concise. While there aren’t a lot of guidelines that say whether your paragraphs are accessible or not, there are a few things to keep in mind when writing content for a website:

  • Keep it short

    • If you can say something in 5 words instead of 20, say it in 5. People typically don’t like to read. They especially won’t read something if they think it’s too long.

  • Passive Voice

    • Don’t use passive voice unless absolutely necessary. Using the direct alternative tends to be easier to understand and shorter than its passive counterpart.

  • Redundancy

    • Saying the same thing twice in different ways is usually just a waste of effort. Users rarely will benefit from having the same thing said to them twice. (This bullet point is a good example of what not to do.)

  • Variety

    • If your content is long, try to vary the length of sentences within your paragraphs and even the paragraph lengths themselves. Varying the length and sentence structure helps encourage your users to focus.

Readability also includes typefaces, spacing, type setting, line height, etc. For the sake of keeping this blog post under 50 pages and rehashing too many things that are already taken care of in Bootstrap and Ensemble, we’ll stick to some basic ways to help make your paragraphs more readable.

Justification

It may be tempting to use text-align: justify; on your paragraphs so that they’re all even on both sides. Though this works in print form, it doesn’t carry over to web as easily and is actually considered bad practice for web content. While it may make your paragraphs appear a little neater, the readability of your content suffers. Since justifying content tries to make all of the lines in your paragraphs equal, the spacing between words and breaking up words can be distracting for your user. Hyphenating words across lines isn’t even supported by some major browsers, and even if it is, the Javascript used to do it is extremely large because it needs to be able to reference every English word to find the best way to hyphenate them.

Your users will only care that your content is left justified. Jagged lines on the right side of your page should be the least of your worries when it comes to usability and readability.

Contrast

Make sure your main content has sufficient contrast. If you’re not sure if your content has sufficient contrast, check the background color and font color with WebAIM’s Color Contrast Checker. The contrast between the text on your page and the background is very important when ensuring your content is readable. 4.5:1 for large text (18+ point font, typically) and 7:1 for normal text (14+ point font, typically) or higher if possible. High contrast between the background and the foreground is helpful for all of your users.

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

Posted by kayladsween on February 2, 2017
Posted in: Usability. Tagged: , , , , . 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.”

Let’s Recap

The title element on your page is the first thing users see to know where they are. In the UX Workshop Series: Web Accessibility presentation, I made the analogy that the title of the page is much like the title of a book. The title of the book is printed on the spine (usually) so that before you even pick up the book, you know what it is. Imagine if all books had blank spines and covers, leaving you to search through the pages to see what book it was and what it was about. This is how your users feel when your title is either missing or doesn’t describe the purpose of the page.

Also, having a descriptive page title satisfies Guideline 2.4.2 of WCAG 2.0: “Web pages have titles that describe topic or purpose”. This is a Level A Guideline, meaning it’s a base guideline to follow to ensure your website is accessible.

Making Your Title Accessible and Inclusive

Since most assistive technologies announce the page title before doing anything else, it’s usually your user’s first impression of your website. If your page title just says “CMS.Net” on a create order page or “FNC, Inc.” on a contact page, that’s a poor first impression. Give your users a little heads up as to what they can expect from the page by changing the previous titles to “CMS.Net – Create an Order” or FNC, Inc. – Contact Us”. If your site is uses a layout and different body, make sure your title changes to reflect the purpose of that particular page.

The page title is also important for the following reasons, as outlined by the University of Washington’s Accessible Technology post “Providing an Informative Title”:

  • Appears in title bar or tab in most browsers
  • Appears as the bookmark name if the page is saved as a favorite
  • Identifies the page in search results

Another way to make sure your title is accessible is to ensure there are no duplicate page titles in your website. This can cause confusion to anyone looking at your sitemap. Also, duplicating page titles is just bad practice (a theme you should be seeing – accessibility and inclusive design techniques are just good practice).

Setting Up An Accessible Web Page: The Doctype and HTML Tags (A UX Accessibility Blog Post)

Posted by kayladsween on January 17, 2017
Posted in: Usability. Tagged: , , . 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.

The Doctype Declaration 

The Doctype declaration tells the web browser what version of HTML your web page is written in so that the browser can render it correctly. Even though your page may be complex and have a lot of different bells and whistles, it’s still a document (hence the “doc” part). Documents are just an interface to deliver content to your users. Leaving out this little <!DOCTYPE html> tag can cause the browser to render the content in a lot of strange ways, aptly named “quirks mode” (read more about quirks mode on MDN).

Any time you have elements rendering weirdly, just check to make sure <!DOCTYPE html> is the very first line on your page before hunting for the solution via CSS or trying to compare your implementation to that on Ensemble.

The Lang Attribute 

The lang attribute of the element tells the browser what “human” language the website/document is written in. It’s frequently left out of web pages by developers, but its inclusion is very important. One very common usage of the lang attribute is that it helps all of your users fill out forms on the page. The browser takes the page language to determine what dictionary to use to compare text areas against so that any spelling errors that the user makes are evident prior to form submission. Also, the page language helps any third-party translator translate to your user’s native language and helps search engines easily index your website.

Not having a page language declared or declaring the wrong page language could cause a screen reader to use the wrong accent or pronunciation of words. As Heydon Pickering says in his book “Inclusive Design Patterns,” “if <html lang=”en”> is present but the text is actually in French, you’d hear a voice profile called Jack doing a bad impression of French, rather than a French profile called Jaques using authentic French pronunciation.” Computer Braille display users also benefit from having the correct page language set, since even though the French and English alphabets are fairly similar, in Braille, there are many more differences between English and French. Therefore, not only is it important to declare a language, but it’s equally as important to declare the correct language.

Declaring a page language also helps browsers choose and render system fonts with appropriate character sets. This is more important in languages like Chinese, but can be equally as important for English, Portuguese, etc. Having your content render in fonts that don’t have the correct character sets is certainly inaccessible and not at all inclusive.

Sometimes, you’ll have quotes or blocks of text that may be in a different language from that of your page language. To switch page languages for a paragraph, just put your lang attribute in the paragraph tag you’re using for content in a different language. Take, for example, your page content was in English, but you had a paragraph that was in Portuguese:

htmllang

Not only does the lang attribute do all of this work for you, but it’s so easy. Just add it to the html element of all of your pages. If your page uses a layout, it’s even easier. There’s really no excuse to leave this out.