I am trying to sort through the most accessible way of structuring the navigation links and skip-links on a page. Consider a page with top-nav/header, content, and bottom-nav/footer. Since we can move things around with CSS, there are a a few ways of structuring the source order:
- Put the content at the start of the page and put the navigation links at the end. Put a skip-to-navigation link at the top. Use CSS to move the top-nav to the top.
- Put the navigation links at the start of the page and put the content at the end. Put a skip-to-content link at the top. Use CSS to move the bottom-nav to the bottom.
- Have the source order match the visual display: top-nav, content, bottom-nav. Put a skip-to-content link at the top. That part is easy. Now:
- How do we make sure screen reader users can find the bottom nav? Will they assume all the nav in at the top?
- Should there be a skip-to-bottom-nav link somewhere? Where?
- Are there headers, title attributes, or ARIA attributes I can use to ensure screen reader users will be able to find the navigation and content?
I am interested in hearing others' experiences of skip-links in action, in particular from screen reader users. What designs work well for you?
I had an idea for possible solution: What if the page started with a some text, not visible, but available to screen readers, saying, "This page has a header, content, and footer", with those being links to the main parts of the page, a sort of page map? It could also be worded, "Skip to… header, content, footer", again with those as links.
It would be important for the page map to contain just the few key sections of the page otherwise it would be so long that people would want to be able to skip the page map.
It seems to me that a better solution would be if the key parts of the page could be labelled as such and a screen reader user would be told about the page structure automatically by the screen reader. Perhaps @aria-labelledby, @aria-label, and @role do this; I don't know how these properties actual get used by screen readers in the real world.
Comments
Hi Liam, It's great that
Hi Liam,
It's great that you're putting so much effort into accessibility from the get-go here. I would suggest that you structure your content's source order to match the visuals, as follows:
The skip links should be first, so that users can bypass whatever they want. There should be a skip-to-content link as well as a skip-to-nav link, and a skip-to-footer link if there is content or navigation down there that users may need (it sounds like there is).
In addition to helping with order for keyboard-only navigation, matching the source order to the visual portrayal helps screen readers read the page in a way that makes sense to the end user. Screen reader users need to know where they are on a page, how far in and how much farther to go. By putting skip links at the top, you are educating assistive technology users that there is additional navigation in the footer, so you shouldn't have to worry about any users missing it.
Hi, I had some similar
Hi, I had some similar questions.
Understand-I have read most of the Drupal docs, but I am still getting used to D7, (so please keep this in mind) no amount of documentation will help me get used to it since I'm still learning Drupal termms like views, and such.
Hear's something I wish to know.
Is their any way to create a page that does not have a "read more" link on it?
THat reminds me somewhat of a mobile site deisgn byd default.
I know you support basic and articles as the page formats.
Also, what is the best way from an accessibility stand point to create "Same Page" links that actually work? Can Drupal7 assist me with doing this somehow?
I also know, that manually (just as in the latest version of WordPress) that you can adjust where a page is by the wait number combo box.
But what do all the numbers do?
I mean you could put a 1, 2, 3, or 4 or just about anything for a page wait.
Thanks so much.
Sorry for these questions, but I'm still trying to even now (after all the public beta testing I did do with Drupal7, I'm still trying to get used to it.
Oh, and one last question I thought I'd ask, if anyone could help.
I hear Drupal can power Podcasts? Are there modules oor themes for Drupal7 that could help me with this?
While I don't mind mnaully coding an xml feed for a Podcast, I find that always hand coding is somehwat annoying. I think Hand coding is good, but too much is just about as bad as opening up Notepad here on Windows and writing a raw HTMl file without the benifits that Drupal clearly does provide.
Feel free to send me private email in addition to this thread by sneidn gan email to
keithint1234@gmail.com
Thanks!
Great plan, Liam!
Liam, it's understandable that you're a bit confused by all the different options for improving the accessibility of your presentation. I think the bottom line with the specific question you're asking is that we don't know which approach works best for the most people.
Kat's answer gives you an approach that is simple and valid and will work. It sounds like you've found other sources that suggest "content first." I see a lot of merit in those approaches, and they might well work better than the one Kat has suggested. But if the only reason you pick one of these approaches is that it's easier for you to apply, then go with that approach.
Once you've decided which accessible approach that appeals to you, the most important thing within your site is to be consistent. In other words, don't try one approach on one page (or class of pages) and other approaches on others. Visitors to your site need to be able to learn what they can expect.
And you can help them learn what to expect if you add an "Accessibility" link to your footer. On your Accessibility page, tell what approach you've taken to improve accessibility on your site. If you want to be especially helpful, promise to try to remove any barrier to accessibility that you've overlooked if anyone who encounters that barrier will tell you about it. (It's impossible to make your page perfectly accessible to everybody forever. Acknowledging that fact and that you've done your best is a great start. A continuing commitment to maintaining and improving the accessibility of your site is a great finish.)
From your question, it sounds to me like you're reading the right sources and thinking about the issues properly. You are right that there are advantages to being able to define a role for each region of the page. Look into HTML5. It has adopted many of the features of ARIA that make this possible. Bruce Lawson's book on HTML5 is a great resource, as is our HTML5 group.
You're right — not all browsers, screen readers, and other user agents support the latest techniques. So the trick is to be sure that you use them in ways that degrade gracefully — in other words, in ways that still provide a fully functional website to people whose setup won't support your extremely slick design.
Oh, one other thing: Keep up the conversation. Share what you learn. As with Drupal, accessibility is an ever-changing field. We are all still learning. Glad to have you involved!
ARIA is on the rise
Thanks for your replies. I did a bunch of reading, including this survey of screen reader users. ARIA landmarks are on the rise and skip links on the decline, so I have created an ARIA-centered approach, with skip links as fallback, hidden from ARIA users. Once ARIA becomes even more common, these can be removed. Source order matches appearance, which makes things easier for sighted users who also use a screen reader. My header also includes elements with @role search and navigation, using aria-label to differentiate the navigation elements.
<body><div id="skip" aria-hidden="true">
<a href="#main">Skip to main content</a>
<a href="#footer">Skip to bottom navigation</a>
</div>
<div id="header" role="banner">...</div>
<div id="main" role="main">...</div>
<div id="footer" role="navigation" aria-label="Bottom navigation">...</div>
</body>
Validation is an issue with ARIA. It validates with the HTML5 doctype or with this build of XHTML1:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+ARIA 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-aria-1.dtd">Note that these validate the document as a whole, it does not check that only allowed values for @role are used.
Liam, Your approach above is
Liam,
Your approach above is very interesting. Let me be clear to you and Cliff both that my suggestion is for one that will validate, be cross-browser compatible, and will work with the majority of assistive technologies at the moment, and in the foreseeable future (of the next couple of years). Similar to IE6 support without the rage that goes with it, coding for this type of accessibility support is still something that I strongly recommend until ARIA/HTML5/CSS3 are far more widely and consistently supported. That having been said though, your suggestions and approach here are very valid and interesting, worth implementing, and certainly also worth exploring. This kind of code is still valid (even if not always by a filter), and this exploration is important.
Have you found anything interesting about the definitions of ARIA roles vs. HTML5 roles? The matchups for ARIA roles where HTML5 roles are defined but ARIA roles are not is often intuitive, however this can change browser-to-browser. What are your thoughts on ARIA roles in addition to HTML5 roles?
In the latest draft of HTML5,
In the latest draft of HTML5, @role is defined completely with reference to ARIA, so there is no conflict. Many HTML elements are defined as conveying the same semantics as ARIA @role values, in which case there is no need to include @role.
AT
@Liam, is it your understanding that assistive technology makers will start looking at HTML5 semantics such that we no longer need to implement ARIA @role values? Does anyone know if assistive technology has started doing this or are they still playing catch-up implementing ARIA?
www.pixotech.com
As far as I've been aware, AT
As far as I've been aware, AT hardware and software developers are concentrating on rolling ARIA into their work, as this is ARIA's purpose.
You can see in the HTML5+ARIA Roles test that there are still problems in several ATs, though development is working toward unification.
Link here - http://www.accessibleculture.org/research/html5-aria-2011/
I commented a bit more on this below. This is why it makes me uncomfortable to consider substituting HTML5 for ARIA. They can and should work together to maximize accessibility and compatibility.
HTML5 is just a working draft
HTML5 is just a working draft while ARIA is a Candidate Recommendation. User agents should be starting to implement ARIA. We shouldn't expect HTML5 support yet. However, once HTML5 is widely deployed, some elements will not require ARIA since the semantics added by ARIA are already included in the element. For example, while the following is valid, the @role has no effect:
<nav role="navigation">Host language vs. ARIA
Hello Brandon!
HTML5 includes only some of semantics offered by ARIA. And the question is not, if screen reader producers concentrate on working with ARIA enriched mark-up (it is not much extra work here), but if the main browsers do their part implementing the proper mappings between new structured mark-up elements in HTML5 and the systemwide accessibility API, such as for example MSAA or UI Automation on windows.
As long as this is not clear it is a good idea to double the semantics by including the ARIA roles with the same meaning in the new elements.
Ciao Mario
Mario Batusic - Linz, Austria
Omitting aria-role makes me
Omitting aria-role makes me nervous. There is no immediate need if you're using HTML5 and your agent is totally compliant with HTML5, but the standard is still in flux, and there are still a number of assistive technologies or user agents which support ARIA but have spottier HTML5 support. The development cost of including the aria-role attribute is minimal, while the support guaranteed is pretty worth it.
That having been said, what is the baseline of interest in this case, and what browser(s)? I work in higher ed, and so most of my concerns go toward making something as accessible as possible for everyone across many browsers, including older versions, and older versions as well as current ones of screen readers, Braille displays, switch software, etc.
@role and the Role Attribute
another point of consideration: the @role attribute used by ARIA has been developed in tandem with the Role Attribute (formerly, the Role Module)
http://www.w3.org/TR/role-attribute/
this particular document is expected to be in candidate recommendation later this spring, and it is expected that the Role Attribute will reach maturity in tandem with WAI-ARIA 1.0
@role versus @aria-role
aloha --
i understand the hesitancy in using a naked role attribute in HTML5, but want to add some background/persepective as a member of both the ARIA Caucus of the PFWG of W3C and as a member of both the HTML WG and the HTML Accessibility Task Force -- the HTML A11y TF is attempting to negotiate with the editor and chairs in order to get @role added to the global list of attributes (with a few explicit exceptions) so that landmarking is available to all users via @role and not just for those using an assistive technology...
i am, however, going to pose the @role versus @aria-role question to the ARIA caucus in order to obtain it's advice on use of @aria-role versus @role -- aside from AT processing (right now, ATs look for @role and not @aria-role) there is also the issue of validation, and currently, @role is deemed valid by the HTML5 validator at validator.nu, but you do bring up a very valid point as far as consistency of the use of ARIA is concerned and a means of avoiding potential conflicts with MLs that may have their own native @role attribute