skip to main content

TAMU Webmaster's Blog

Information and insight from the A&M Webmasters


Making Accessibility Better with ARIA, Not Worse

Some takeways from Jared Smith’s ARIA Gone Even Wilder session at the Environment for Humans Accessibility Summit.

ARIA stands for Accessible Rich Internet Applications. As Jared Smith explains, “ARIA allows us to expand the vocabulary of HTML to include things that screen readers already understand.”

To do this, web developers use HTML tags and attributes. Probably the most important of these attributes is role, but there are many others, such as aria-label, aria-describedby, etc.

Most HTML5 tags have default ARIA roles. For example, an h1 tag automatically has the ARIA role of ‘heading’. Use HTML, then use ARIA to fill in the gaps.

Roles don’t change browser behavior. That is, giving a span the role of button doesn’t make it act like a button. If you define roles with ARIA, you must also support the standard anticipated behavior. You must add CSS or Javascript to make your span act like a button (clickable, etc.) If not, it will require overhead/orientation for everyone, to teach them how to use your widget. You don’t need to duplicate native roles. If you define a button using the button tag, you won’t have to worry about faking it.

ARIA supports a lot of user interface widgets (such as menu, slider, checkbox), and users need to learn how to use them. They may know tab only and not arrow keys. What if you do it right and they don’t understand? Should we break the rules/standards? No.

Common misunderstandings about ARIA roles:

  • Navs are rarely menus! Menus are File-Edit-View etc.
  • Lists are rarely a listbox. Listbox is a select menu.
  • Tables are rarely grids. Grids are interactive.
  • Dynamic content is rarely a live region (aria-live=”assertive”) If focus is set to it, it isn’t a live region.
  • Important information is rarely an alert. Alerts are read immediately.
  • Not all groups of links are navigation. Navigation lets you move within a page or across the site. Social icons are not navigation.
  • jQuery dialogs always have role=dialog regardless of their content, which makes them mostly inaccessible.

Navigation by type is not yet widely available. You can’t jump to it. Landmarks are usually identified anyway. It would be great for browsers to support keyboard navigation by structural elements (headings, nav, main) and ARIA landmarks. Then we wouldn’t need skip links.

Landmarks and labels

You can use aria-label or aria-labeledby to differentiate multiple landmarks of the same type.
Labels vs. descriptions: label is necessary, description is advisory
There is no aria-description, since aria-labeledby is better. It might be read twice if it’s already in context.
ARIA labels replace the link and label text. So a screenreader reads aria-label=”PDF” instead.
Use off-screen or aria-described by.
Ensure labels are on the focusable element, not parent or child or container.
HTML input attributes, however, can change behavior.
Users assume that if you can tab to it, you can interact with it. Don’t put tabindex=0 on text, only on links and buttons.

ARIA roles are an example of progressive enhancement – usually you can’t make your website less accessible by using ARIA (though it’s possible if you do it wrong), but older browsers might not see the newer attributes.

Wednesday, January 28th, 2015 Accessibility No Comments

Responsive Images for 60 Million Websites

Last fall I joined the W3C‘s Responsive Images Community Group after being inspired by (and having lunch with) Mat “Wilto” Marquis, the group’s chair, when he spoke at An Event Apart in Austin. The RICG calls itself “a group of independent designers and developers working toward new web standards that will build fast, accessible, responsive websites.” Mostly my contributions have been limited to fixing typos on Github and making wisecracks on IRC, but I’m pleased to have contributed to the newly-released RICG Responsive Images WordPress plugin. (Technically, I added support for PHP 5.3 and below, versions which don’t support function array dereferencing.)

The RICG’s first achievement was to push through a new HTML element – picture – along with its friends srcset and sizes. These allow web developers to offer images in various sizes and let the browser decide the best one to use. A retina phone can display the 2X retina image, an older feature phone can display a little 200px image, and your ultra-wide monitor can display a full-bleed 1920×1080 image. Best of all, the browser only downloads the image it needs – no double download.

I consider responsive images a perfect example of progressive enhancement  – fully supported on Chrome and Opera, and partially supported in Webkit and Firefox. Even Microsoft is working on adding these features to Internet Explorer its new browser. And the Picturefill script adds responsive images capabilities to any browser. Until now, responsive web developers like me have been sending oversized images to be squeezed onto little phones, wasting much of our users’ bandwidth. Mat Marquis says that people in Africa actually have to keep lists of which websites they can’t visit without draining their entire monthly bandwidth. So if we use responsive images when someone’s mobile browser doesn’t support them, the user experience will be no worse off. But if the browser does, his or her experience will be much faster and more pleasant. An image on a mobile phone might only need to be 1/5 the size in kilobytes of an image on a typical laptop.

The WordPress plugin is a first step to adding responsive images to the core of WordPress itself. When that happens, webmasters of 60 million websites can upload large, clear images, and their visitors will only download the image size they need. The plugin comes bundled with Picturefill, and since WordPress already keeps track of multiple image sizes automatically, the future looks good.

Resources for responsive images:
Responsive Images in Practice – Eric Portis
Responsive Images – RICG
Why Responsive Images Matter – Mat Marquis

Wednesday, January 21st, 2015 Accessibility, Mobile Web, Programming No Comments

Online Web Accessibility Conference

For those of you not on the uweb mailing list, this announcement was sent last week:

IT Risk Management will be sponsoring a meeting room to view the Environments for Humans Accessibility Summit on September 9-10.

The summit will feature several notable web accessibility experts speaking on a wide-range of topics over a two day period. Attendees can join us at no cost. Come for two full days of sessions, or come and go as your schedule allows.

RSVP required. Email by Friday, August 1 to reserve a seat.

Kyle Boatsman

Monday, July 28th, 2014 Accessibility No Comments

Web Accessibility

Yesterday at the IT Forum we had a good discussion about web accessibility.  One of the things that was noted in the automated scans of campus web pages was that the primary areas of non-compliance were lack of “alt” attributes on images, lack of “skip nav” links, and lack of label tags on associated form fields.

It is easy to look at those things and think they are just minor details that don’t matter that much.  But let’s look at how important they really are.  Last year we presented an Accessibility Showcase to campus, and one of the presentations was a description of screen readers and then a live demonstration given by a blind student.  Watch or download the video and see how hard it is to navigate some of our own sites here on campus.

Tags: , ,

Thursday, January 28th, 2010 Accessibility 2 Comments

IT Forum Meeting

Don’t forget that the IT Forum meets tomorrow (Jan 27)  afternoon at 3:00 in Room 601 Rudder Tower.

CIS will be talking  about Web Accessibility, the new state and university requirements, and the automated system they have available to check web sites for various accessibility issues.

If you manage a website I would encourage you to attend — if you haven’t already, you’ll likely be getting a call from these folks about scanning and updating your sites, and this is a good opportunity to learn ahead of time what to expect.

Tags: , ,

Tuesday, January 26th, 2010 Accessibility No Comments

First things first on your web page

Search engine optimizers believe that the first words that appear on a website will be given the most weight on search engines. Sometimes superstitiously so: I’ve seen questions on SEO forums asking if the order of the meta-keywords makes any difference in rankings, and others swearing that it does. (A better question might be whether meta-keywords make any difference at all, which is Nope. Still, I would put the most important, most unique keywords first, and the most general keywords last). But if your success on the Web depended on what Google thought about you, you might tend to get a little superstitious too.

Superstition or not, prioritizing your content is a good rule. Search engines do assume that if you give a keyword the prominent place at the top of your page, especially in your title, it must be important to you. They may not even pay as much attention to your whole page, if it’s very long, just the first part of it. How long is long depends on the search engine, and webmasters swear that it changes. But surely there is a limit. Search engines might display only the first 66 characters of a title, and may ignore the rest. Or they may not. They might display the first 150 characters of your meta-description, and ignore the rest. Or they may not. If you don’t discuss a topic until the end of a long web page, search engines might assume that it isn’t very important to you. Or they may not.

Putting the most important words first in your title has another benefit – it makes better bookmarks. If someone enthusiastically bookmarked a dozen pages from the College of Science, but all the titles began with “Texas A&M University, College of Science”, then all the resulting bookmarks might read “Texas A&M University, College of”, or “Texas A&M University, College of Science, Department of”. That leaves something lacking. Fortunately, the College of Science doesn’t do it that way, and their titles aren’t cut off.

For example, here’s how I would write a typical academic page title: “Page Name: Department Name: Texas A&M University”. Certainly “Texas A&M University” doesn’t need to go first, unless the page or department name is very generic, as in the case of the Texas A&M Foundation or the Texas A&M Facts page (though even that page could be called “Facts about Texas A&M University”). There are lots of web pages about Texas A&M – that’s what my team specializes in – but there are not as many pages about what you specialize in. So put the name of your topic first.

By the same token, try not to leave off “Texas A&M University” from the end of your departmental page titles. You have at least 66 characters to tell visitors what your page is about, and you want to use those characters to the fullest. If you run out of room, you might instead say “Texas A&M [department name]”. When I have extra room, I even add “College Station, Texas,” thereby hitting the popular generic keywords , “university”, “college” and “texas” (see, the name of our town is optimized for search!).

A title that merely says “About Us” or “Home” won’t mean much as a bookmark later. Imagine an enthusiastic college shopper with eight bookmarks that said “Apply Now” and twelve that said “Admissions”, trying to remember which school was which.

Thursday, April 23rd, 2009 Accessibility, Search No Comments

Web Development Tools and Local Validators

Nick DeNardis over at .eduGuru recently wrote a post on web development tools. These browser plugins and websites help developers with issues pertaining to website validation, link checking, accessibility, page performance and more. He listed the W3C Markup Validator (aka HTML Validator), but did not list the W3C CSS Validator or the Feed Validator. He did list some browser plugins that will do similiar validation.

I’d like to add one thing to his list for universities in general – running a local copy of the W3C validation services is very valuable. We already run a local copy of the Markup Validator and will very shortly have local copies of the CSS validator and Feed Validator running as well. Having a local copy really helps when validating sites that are still behind the firewall and not accessible via URL to the W3C copy.

You can also set Firefox to use the local copies of the validators as well which will usually lead to faster validation results. It is a good idea for any web developer to take a look at Nick’s list and play with some of the tools you haven’t seen before.

Tags: , , , ,

Wednesday, January 14th, 2009 Accessibility, Browsers/Plug-ins, Future Projects, HTML 1 Comment

Getting back to Normal

The Web Accessibility Showcase is over now. Thank you to everyone who was a part… from those who helped organize it, to the speakers, and to those of you in the live and online audience. We hope it gave you some worthwhile information and sparked an interest in making accessibility a part of your own projects. Links to all of the video brodcasts and presentation downloads are available at

We will definately be doing more of these types of things in the future – both accessibility related and in the area of basic web development – in order to create a more informed and more involved web developer community. These would probably be single day workshops rather than week long events, but we definitely want to keep the interest level raised. We’re also interested in combining efforts with others on campus – UWeb, IT Forum, or Instructional Technology Services just to name a few possibilities.

A couple of ideas that we had were:

  • Modern XHTML/CSS
  • Walking through Section 508 Checklists
  • Using the Rhythmyx CMS

If you have any other ideas or requests for topics please send them along or post them as a comment here.

Monday, September 22nd, 2008 Accessibility, Future Projects, Miscellaneous No Comments

Web Accessibility Showcase – New Streaming Source

The Web Accessibility Showcase will not be broadcast Thursday or Friday because the room we will be in (Rudder 302) is not wired for their equipment. We will instead be streaming the presentations from a third party site —

As an FYI, for those of you who missed it this morning, Tracey Foreman and Kristin Mathe did a great job of demonstrating the JAWS screen reader and showing how web accessibility affects real users. We’ll get the link to that broadcast published as soon as we receive it.

Wednesday, September 17th, 2008 Accessibility 2 Comments

Wednesday Showcase Session – Legal Requirements

I just received a call from CIS’s ITIM group, who was schedule to present our Legal Requirements segment of the showcase tomorrow that they will be unable to attend and give the presentation. Since it is a bit late to try to find another speaker we forced to cancel the session.

As substitute resources we urge you to review the presentation given on Monday by Glenda Sims (links to the TTVN broadcast and to the PowerPoint file are now online at We would also recommend the following websites as resources detailing web accessibility policy, law, and guidelines at the national, state, and local levels.

We apologize for the inconvenience and urge anyone who is interested in the topic of web accessibility policy to contact any of us and we’ll be happy to have a thorough one-on-one conversation.

Tuesday, September 16th, 2008 Accessibility 1 Comment