I get why you have a JS listener on the h2 titles of the block, but if has to navigate a site sans-mouse or with VoiceOver, collapsiblock doesn't work as expected.

This would be better.
<h2 class="title collapsiblock collapsiblockCollapsed"><a href="#">Popular Links</a></h2>

Then the listeners can be modified for ".collapsiblock a"

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dstol’s picture

This is a start.

Edit: I completely attached the wrong patch file. I'll have it up here once I get home.

dstol’s picture

Here's the correct patch.

dstol’s picture

Status: Active » Needs work
+      h2 = $("<h2/>").addClass('collapsiblock');
+      h2.append(
+        $('<a href="#" />')
+          .text($(titleElt).text())
+          .click(function () {

Because there is no jquery.live() function in 1.2.6, you have to create the element on the fly and add the click event to it.

I really don't like this method. I'm sure it's possible to add a custom tpl that does this same work without hacking the DOM.

Also, there are way too many calls to $(this).parent().... there is probably a better way to get at it.

Powered by Dreditor.

gagarine’s picture

Thanks for the patch.

I really want to improve the accessibility and keep this issue critical.

I will make more investigations to know if they are a way without changing the dom. I'm afraid we can break a lot of theme by adding a link in the title. But I don't exclude the possibility to do it if it's the only one...

Everett Zufelt’s picture

Generally speaking a keyboard only user and screen-reader* user can interact with any element with an event attached.

1. The element must be able to receive keyboard focus.
2. It must be visually apparent that the element has received focus.
3. You must allow for a keyboard activation event (enter) and for a mouse activation event.

* The problem for screen-reader users is that even though they will be able to activate using the keyboard, they will have * no * idea that it is possible. Screen-readers communicate the semantic property of an element to the user. e.g. a = link input type=button = button. This means that they are told that this is an interactive element. If the markup doesnt indicate that the element is actionable then the screen-reader user will have no idea that they can perform an action on the element.

Possible solutions:

1. Use an element with an explicit actionable role like button or anchor

2. Use the WAI-ARIA role attribute to communicate the role to assistive thechnology. Note: this only works for some users as WAI-ARIA is still a draft recommendation of W3C and is not fully implemented in all technology, older technologies will never support WAI-ARIA.

<h2><span role="link">My heading</span></h2>

This tells assistive technology that it should recognize the span as having the semantic role of a link. This means that the user will understand that an action can be performed. If a keyboard event is attached then when the assistive technology user presses enter (or whichever key is attached) the action will be performed.

The Roles Model | Accessible Rich Internet Applications (WAI-ARIA) 1.0
http://www.w3.org/TR/wai-aria/roles

dstol’s picture

Thanks for your input Everett. I had been proceeding down the route of making the JS event listener active on the anchor tag. I'll read up on ARIA and see if I can't build a solution using it.

I'd also really appreciate your help testing this thing out once it gets to that point.

Everett Zufelt’s picture

Edited mycomment again to expose the code for the heading.

<h2><span role="link">My heading</span></h2>

Using the role attribute, definied in WAI-ARIA 1.0, you can explicitly communicate to assistive technology that the span is a link.

dstol’s picture

I've made some pretty good progress. http://github.com/unn/collapsiblock/tree/aria

I've still got to fiddle with the whole cookie remembering state of block but we're almost there.

Everett Zufelt’s picture

Again, to be clear, by enabling the element to receive focus and to accept a keyboard event it is able to be controlled via the keyboard. By showing that the element has received focus (visual style) sighted keyboard only users have a visual affordance to indicate that an action is possible. Using ARIA, users of newer supporting technology will receive an affordance (usually textual) regarding the role of the element.

However, users of older assistive technology, like older screen-readers, will not receive any affordance that an action can be performed, even though the action will likely be performed if they guess at it.

HTH

gagarine’s picture

It would be nice if user on normal browser can also use tab.

If links don't break to much it's perhaps the fastest and easy way. We can aslo use link AND WAI-ARIA 1.0

Everett Zufelt’s picture

@gagarine

My suggestion would ensure that all users would be able to tab to the element, with a visual indication that the element has focus. Just to clarify, users of assistive technology rarely use specialized browsers, they use specialized software to interact with the browser.

For example, my screen-reader parses the DOM provided by the browser and renders it as text to be read aloud. When an event changes the DOM in the browser the screen-reader is made aware of the change in the DOM and modifies the text accordingly.

HTH

dstol’s picture

@gagarine I plan on integrating my aria branch with the a-tag branch, as I didn't really understand the approach until Everett's post in #9.

I'll post an update once I've gotten some where with it. Stay tuned.

gagarine’s picture

Ok I get it...

Thanks, you two.

dstol’s picture

I've just updated the aria branch. It still needs a few tweaks but I'd say it's 90% there.

gagarine’s picture

@dstol do you plan to make more changes? Can you post a patch when you finish (or when you are tired of...)? It would be great

Thanks

dstol’s picture

Yeah, probably just a few more tweaks.

dstol’s picture

On second glance here, I do think I've worked it out. I'll post a patch once I'm able to this evening.

dstol’s picture

Status: Needs work » Needs review
FileSize
4.49 KB

Sorry this took so long to get to you.

gagarine’s picture

Assigned: Unassigned » gagarine
Status: Needs review » Needs work

Thanks for your work. I will take this one as a starting point.

I'm not sure than collapsiblock_preprocess_block and the bock.tpl are necessary (those two files are removed from the -dev). Using template cause a lot of themes incompatibility.

gagarine’s picture

Status: Needs work » Fixed

Fixed thanks to all http://drupal.org/cvs?commit=430738.

I'm very sorry dstol I forget to add a credit in the commit :/.

gagarine’s picture

Status: Fixed » Closed (fixed)
dstol’s picture

Don't worry about it, I'm just glad I can help.