Faceted searches and ARIA roles?

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"> [COLOR=#008000][B](Do I need a role if I'm using HTML5 aside?)[/B][/COLOR]

    <dl id="facets-list" role="application"> [COLOR=#008000][B](It's a list, but it's interactive, so I didn't think the "list" role was appropriate...correct?)[/B]
[/COLOR]
        <dt>Facet Group 1</dt> [COLOR=#008000][B](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?)[/B][/COLOR]
        <dd>
            <ul> 
                <li>
                    <label for="checkbox1">Some Label</label>[COLOR=#008000] [B](Since I'm using label for, I shouldn't need the aria-labelledby stuff, right?)[/B][/COLOR]
                    <input type="checkbox" id="checkbox1" name="checkbox1" role="checkbox">[COLOR=#008000][B] (Do I need to indicate the aria-checkbox state?)[/B][/COLOR]
                </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…

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.

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! :slight_smile:

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

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.

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. :slight_smile:

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.

Crusty:

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… :frowning:

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.

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.

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.

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.

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…

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

In other words, the only time to use ARIA 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.

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?

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…

As with a great many other things Opera, HOW ABOUT THE ONE BUILT INTO IT?!? :smiley: 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.