Faceted searches and ARIA roles?

[TaliaJ2]

I'm working on a project with a faceted search, and I'm confused about how to indicate the aria roles. In the high-res version, the site has facets (search refiners) on the left, and the results on the right.

The structure of the facet region is roughly (questions inline):

<aside id="facets" role="complementary"> (Do I need a role if I'm using HTML5 aside?)

    <dl id="facets-list" role="application"> (It's a list, but it's interactive, so I didn't think the "list" role was appropriate...correct?)

        <dt>Facet Group 1</dt> (This describes a group of controls to refine a search...do I use aria-describedby on the dd, or is the dt / dd relationship enough?)
        <dd>
            <ul> 
                <li>
                    <label for="checkbox1">Some Label</label> (Since I'm using label for, I shouldn't need the aria-labelledby stuff, right?)
                    <input type="checkbox" id="checkbox1" name="checkbox1" role="checkbox"> (Do I need to indicate the aria-checkbox state?)
                </li>

                <li>
                    <label for="checkbox21">Some Label</label>
                    <input type="checkbox" id="checkbox2" name="checkbox2" role="checkbox">
                </li>

            </ul>
        </dd>

    </dl>

</aside>

My apologies, I realize these are basic questions, but I'm finding I'm a little confused about the application of the standards.

Until next time...

[rguy84]

I would argue that you are pushing it using the <dl> there, but that is just my personal preference. In my opinion the application role would need to be defined higher up because there are more parts to the page.

You are correct, since you are using <label>, aria-labelledby is redundant, and not needed. You don't need the checkbox role since you are using a standard checkbox.

I am assuming, <label for="checkbox21">Some Label</label> is a typo.

[TaliaJ2]

Thank you for the reply! We have a search region above this in the header as well as a main content area with results. Given your thought, I'll move application to apply across the whole page -- the user can interact across all areas with the same dataset.

I appreciate the clarification on checkboxes and labels, will remove those roles.

// Yes, typo on the checkbox label, day 6 of high fever and flu. Probably best to wear sterile goggles while reading my posts!

[rguy84]

Are you making an actual application? Or allowing the user to search then to drill down?

[Stomme poes]

Be very very very careful with role="application". It removes the screen reader's navigation methods. Plain text in a box may not be navigable or readable. Always test that the thingie with role=application actually works.

I actually don't know of any defined relationship announced between dt's and dd's actually, but the parent is a definition list, which is a list, which screen readers have already encountered before (DL is an old tag).


You have form elements. Is this a form?

Just so you know: aria-labelledby will override (replace) any actual labels you have in your code.

It almost doesn't matter that HTML5 is adding native roles to HTML elements: while you don't want to add a role to something that actually conflicts with its native role, most things' roles are either ignored (by older screen readers who already "know" what types certain HTML elements are anyway) or incorporated into known roles if it does understand roles. I'm not sure what screen readers do when you the author add a role that conflicts with a native role, though I thought the author-stated role was supposed to override the native role.

A general rule of thumb for when to add roles could be: only manually add roles when you're using an element without a defined (or matching what you're building) role (like using a span to be a "handle" in a slider, and using a div to be the slider), or to add landmark roles to the document (banner, main, navigation).

I'd be wary of doing things like <span class="check" role="checkbox" onclick="dosomejavascriptstuff"></span>. Ryan pointed out that you don't need a role of checkbox on actual checkboxes: they already have that role, and older screen readers don't need a role, because they know what a checkbox is and how to interact with it anyway.

[TaliaJ2]

Thank you for the additional replies. I ended up getting very sick, so I'm just now returning to the project.

Hmm. At this point, I think I'm going to have to lean on a friend who uses a screen reader to do some testing...I've made an initial guess, but I think this will require someone who's comfortable with the tools.

Stomme poes, I appreciate your sensible advice on using roles. I've pulled some additional aria roles out of the code that were redundant as a result. Less stuff to type is always good.

[deathshadow60]

I'd be asking why is a FORM an ASIDE (it probably isn't -- not that anyone uses ASIDE for asides... not that most people even know what an aside is, and no it does not mean a sidebar of unrelated content), why does it need an ARIA role in the first place? where's your FIELDSET? What the blue blazes makes this a term and definition...

In other words the exact same nonsense as I've come to expect from everything built with the idiotic train wreck known as HTML 5. Nothing like using TWICE as much markup as necessary and pissing on accessibility while at it.

You don't have an "aside" you have a form... you don't have "facets" you have a FIELDSET. You don't have a DT and DD, you have a LEGEND for the FIELDSET and the INPUT/LABEL inside said FIELDSET... and then the unordered list for christmas only knows what... or the roles that are redundant to the element's TYPE (serious whiskey tango foxtrot).

Perfect example of everything WRONG with this HTML 5 BS and bloated ARIA nonsense... and a stellar example of why I keep telling EVERYONE to forget that nonsense and stick with what actually WORKS in the here and now -- 4 Strict and/or XHTML 1.0 Strict.

<fieldset id="facets">
	<legend>Facet Group 1</legend>
	<label for="checkbox1">Some Label</label>
	<input type="checkbox" id="checkbox1" name="checkbox1" />
	<br />
	<label for="checkbox21">Some Label</label>
	<input type="checkbox" id="checkbox2" name="checkbox2" />
</fieldset>

HTML5 idiocy -- or more specifically the above being how to take that idiocy and shove it where it belongs. FIELDSET, LEGEND, INPUT, LABEL -- PERFECTLY GOOD functioning working tags without any of that extra bloated ARIA or HTML 5 BS that does absolutely NOTHING useful or better.

I can't believe people are buying this snake oil...
'Twas Pirelli's Miracle Elixir,
That's what did the trick sir,
True, sir, true,
Was it quick, sir? Did it in a tick, sir?
Just like an elixir ought to do.

[Stomme poes]

Crusty:

not that most people even know what an aside is, and no it does not mean a sidebar of unrelated content), why does it need an ARIA role in the first place?

The role="complementary" on the <aside> is a landmark role which is pretty much just there as an additional navigation aid, though pretty much limited to screen reader users (dunno about something like Dragon). You can call up a list of landmark roles and go directly to one, whether the author has added skip links to it or not.

[deathshadow60]

The role="complementary" on the <aside> is a landmark role which is pretty much just there as an additional navigation aid, though pretty much limited to screen reader users (dunno about something like Dragon). You can call up a list of landmark roles and go directly to one, whether the author has added skip links to it or not.

Funny, I thought that was LEGEND's job... or LABEL's job.. or numbered heading tags job.. or caption's job... or TH's job.. but of course since nobody uses those properly, the answer is to just throw even more code at it - because throwing more code at a problem is ALWAYS the answer...

[Stomme poes]

Landmarks are to mark up large sections of a page or application. They are to be used sparsely, and basically do the job your eye does when you do a quick eyeball of a page's structure.

[deathshadow60]

and basically do the job your eye does when you do a quick eyeball of a page's structure.

Which I think is where most of my problem with it lies -- since I wouldn't be trying to deliver content to non-sighted the way I would to sighted in the first place -- that's kind-of the point of semantic markup; say what things are, NOT what they look like. It just strikes me more as a really lame way to justify presentational markup concepts... "quick scan of the eyeball" of which structure? The desktop/laptop screen layout? The print layout? the small screen layout called with media queries? The CSS off appearance? The code structure?

But then, I design my non-CSS structure FIRST, then my screen.css layout, then my print layout... I've not seen any bonus that ARIA roles would actually add to my non-CSS version that just properly using headings (as in all the existing HTML 4 heading-type tags; H1..H6, LABEL, LEGEND, CAPTION, TH) and indicating topic-breaks with horizontal rules couldn't do.

Unless you consider more code for nothing to be a bonus. Much like HTML 5, I'm just not getting what's "better" or even WHY anyone would want to use it. I see NO tangible benefits.... What I do see is a bunch of extra code for nothing.

The above code with the aside, DL abuse, UL for nothing, and roles to basically do what fieldset and legend are ALREADY supposed to be able to do being a perfect example of that. At WORST using fieldset/legend properly it might need an extra DIV because you can't entirely trust fieldset with CSS, and a span inside the legend for same... and that's the fault of the browser makers, not HTML.

[stevefaulkner]

Hi Talia, the only ARIA that I woul suggest to use is role="complementary" on the aside, this provides the role information for aside. for screen reader users that browsers have not implemented yet (pretty much all browsers except firefox).

You do not need any of the other ARIA markup. It is either redundant or not useful. native HTML controls such as checkbox already have information about role/state etc exposed by browsers to the accessibility APIs. use of role=application should only be used in very limited circumstances and is not useful or desirable in your example code.

(It's a list, but it's interactive, so I didn't think the "list" role was appropriate...correct?)

list elements are already mapped to list roles in accessibility APIs

(This describes a group of controls to refine a search...do I use aria-describedby on the dd, or is the dt / dd relationship enough?)

I would suggest using fieldset/legend as suggested previously by the rather arrogant deathshadow60.

(Since I'm using label for, I shouldn't need the aria-labelledby stuff, right?)

correct

(Do I need to indicate the aria-checkbox state?)

no this info already provided by browsers.

Note: in most cases ARIA is not required for native HTML elements unless you are repurposing them to do something other than what they are specified to do.

[rguy84]

The role="complementary" on the <aside> is a landmark role which is pretty much just there as an additional navigation aid, though pretty much limited to screen reader users (dunno about something like Dragon).

AFAIK you cannot navigate using landmarks in Dragon. I found an article by Derek Featherstone talking about other AT. The article is slightly old, so I don't know how much changed.

[Stomme poes]

Steve, thanks for weighing in.

Ryan, thanks for the link. It looks like some of that same research was in his 2011 Fronteers Conference talk, where he also mentioned (on that same map setup) how the buttons should work in Dragon...

[rguy84]

I didn't read the article fully, but I assume the map exposes some controls that can be grabbed onto, or use dragon mouse/grid, whatever it is called.

Off Topic:

this is my first time at home using the new layout in chrome, you cannot tab out of the reply box?/fail

[deathshadow60]

Note: in most cases ARIA is not required for native HTML elements unless you are repurposing them to do something other than what they are specified to do.

In other words, the only time to use ARIA is when you're writing the HTML wrong.

[Stomme poes]

is when you're writing the HTML wrong.

You'll not stop people from building slider controls in forms, not only for when it's the best solution usability-wise, but also of course because everyone and their brother thinks sliders are teh awesome and must be used for absolutely everything and for extra fun decide to build them with jQuery too.


But seriously I love landmark roles for navigation in JAWS, NVDA and Orca. It's really great: unlike skip links, the landmarks list is always available to me in a single keystroke. Roles rock. They kick butt when you're a lazy surfer like I am.

[deathshadow60]

But seriously I love landmark roles for navigation in JAWS, NVDA and Orca. It's really great: unlike skip links, the landmarks list is always available to me in a single keystroke. Roles rock. They kick butt when you're a lazy surfer like I am.

You mean like the accesskeys menu in Opera? The existing heading and anchor navigation in... Opera...

Or am I just spoiled by Opera paying attention to semantic markup without needing any of this extra garbage?

[Stomme poes]

The existing heading and anchor navigation in... Opera...

Or am I just spoiled by Opera paying attention to semantic markup without needing any of this extra garbage?

You're spoiled in that you are able to use Opera at all.

Name one screen reader Opera works with. Just one.

Oh yeah that's right, it works with zero. Though it's worse on Linux, you're pretty much stuck with Gecko for now (webkit slowly coming along...).

/me lightly beats Opera ASA with a willow-switch... bad Opera, bad.

I'm pretty much not a fan of accesskeys. Landmarks are easier to use. Hit ; key, hear your landmarks, pick one. They have standard names so no needing to decipher which keys do what on which sites. Don't have to worry some retard picked your keyboard shortcuts, but I guess you do have to still worry some retard added multiple role="navigations" all over the page...

[deathshadow60]

Name one screen reader Opera works with. Just one.

As with a great many other things Opera, HOW ABOUT THE ONE BUILT INTO IT?!? I assume you're not familiar with Opera Speak, which it's had since version 7? I know, I know, like every other reason I use Opera it's another of those features nobody sticks around long enough to learn about.

Hit V, if you've not used the reader before it will ask to install optional voice binaries (10.5 megs, does NOT require a browser restart)
A and Q to cycle through links
S and W to cycle through headings
D and E to cycle through elements
V to read the current selection (also works with mouse selections)
esc to halt current reading.
shift-esc to pull up the current accesskeys menu

It's by no means perfect, but again it's something built into the browser.

[TechnoBear]

Off Topic:

OK - I'm probably missing something here. Surely somebody using a screen reader is using it for everything on the computer, not just web browsing? So having to close their familiar assistive technology to use something else to browse that won't work with their familiar software is helpful how?

[deathshadow60]

Off Topic:

OK - I'm probably missing something here. Surely somebody using a screen reader is using it for everything on the computer, not just web browsing? So having to close their familiar assistive technology to use something else to browse that won't work with their familiar software is helpful how?

I don't think that's OT, but I have a warped sense of that...

It's a good question -- but I wasn't so much using it as an example in that sense, as it is to show that if they would bother paying attention to the markup, they wouldn't NEED any of this ARIA BS... It's often like they fail to leverage the what has existed in HTML for hooks since TBL came up with it! Of course, the same could be said of the majority of people writing websites who seem blissfully unaware of how to use numbered heading tags, don't realize there are more tags than TR and TD that can go inside TABLE, and never even heard of *SHOCK* label, legend or fieldset.

It also proves a very good point -- normal applications don't have ARIA assigned to them, and they work just fine with said third party assistive tech...

HTML was developed to say what content IS, and to allow you to mark sections with headers, links with anchors, and all the other semantic meanings so that the user agent could best determine how to present the content within the capabilities of the target device -- be it tickertape, Phone TTL, daisy wheel printers, Commodore VIC=20, videotex terminal, braille, whatever. ALL the needed hooks for such things are already present in it -- making ARIA nothing more than redundant bloat, or a lame excuse on the part of third party developers and the people writing websites not to bother paying attention to the markup itself.

Though with the total garbage people have been vomiting up and calling HTML the past decade I can't entirely blame the makers of screen readers for it...

[Stomme poes]

Crusty: I had no idea there was a screen reader in Opera. A screen reader with navigation and all?? Or a read-out-loud program?

Re ARIA: accessible Rich Internet Applications. That means, when your HTML isn't representing a document, but an application, accessibility that's built-in quit working. XHTML2 introduced aaa:roles to fix that. Let the author writing the application indicate what roles the HTML elements were taking within the app.

This later got split into ARIA. When used correctly it turns a broken widget into something you can use with a screen reader. Since you're not going to stop widgets, they had better be accessible.

Technobear: yeah, your controls are usually the same system-wide, which is why I've poo-poo'd FireVox and ChromeVox (though I guess if you're using a "chromebook" thing it doesn't matter cause the thing's not really a computer anyway).

further reading

[deathshadow60]

Crusty: I had no idea there was a screen reader in Opera. A screen reader with navigation and all?? Or a read-out-loud program?

Kind of in-between in a way -- it doesn't say anything until you hit V, but it uses the browsers default keyboard navigation to get around. When something is outlined from keyboard nav it's also treated as focused/selected (despite only being outlined instead of inverse color)... so when you land on a page you hit 'next header' to select the first topic area, and v to read it. Then next and v -- once you get to a section that you're interested in you start selecting through elements. It's not as usable as JAWS, but again I was more pointing at it to show that the hooks already exist in the markup.

That means, when your HTML isn't representing a document, but an application

Which is a hefty part of my issues with it -- but I think the whole 'internet applications' nonsense for normal web pages is pointless bloat and WORSE for accessibility; see why I think XML+Application is pointless BS and the only XHTML I think there's any point to was 1.0 as text/html.

[rguy84]

As with a great many other things Opera, HOW ABOUT THE ONE BUILT INTO IT?!? I assume you're not familiar with Opera Speak, which it's had since version 7? I know, I know, like every other reason I use Opera it's another of those features nobody sticks around long enough to learn about.
</snip>
It's by no means perfect, but again it's something built into the browser.

That's basically /fail sorry to say Jason. Yeah I know it has been around for years. I have known about Opera Voice for about 4 years and use it occasionally, and think it is handy when I have bad days. Give that to people who actually use AT, they'll laugh. In the real world that is like saying you can use the standard keyboard for all programs, but for MS Word you have to use a white keyboard with no labels set in Devorak. Most people would find an alternative. There has been push back to Google making their apps work with ChromeVox junk versus coding correctly, but this is gettin off topic.

Crusty: I had no idea there was a screen reader in Opera. A screen reader with navigation and all?? Or a read-out-loud program?

Basically a text-to-speech program with basic keyboard navigatiblity. If you have heard of ClaroRead, take that, with keyboard hotkeys with the ability to jump to various elements, as Jason said in #20.