Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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"
Comment | File | Size | Author |
---|---|---|---|
#18 | collapsiblock-905534-18.patch | 4.49 KB | dstol |
#2 | collapsiblock-js-905534-2.patch | 2.72 KB | dstol |
#1 | collapsiblock-js-905534-1.patch | 629 bytes | dstol |
Comments
Comment #1
dstolThis is a start.Edit: I completely attached the wrong patch file. I'll have it up here once I get home.
Comment #2
dstolHere's the correct patch.
Comment #3
dstolBecause 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.
Comment #4
gagarine CreditAttribution: gagarine commentedThanks 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...
Comment #5
Everett Zufelt CreditAttribution: Everett Zufelt commentedGenerally 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
Comment #6
dstolThanks 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.
Comment #7
Everett Zufelt CreditAttribution: Everett Zufelt commentedEdited mycomment again to expose the code for the heading.
Using the role attribute, definied in WAI-ARIA 1.0, you can explicitly communicate to assistive technology that the span is a link.
Comment #8
dstolI'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.
Comment #9
Everett Zufelt CreditAttribution: Everett Zufelt commentedAgain, 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
Comment #10
gagarine CreditAttribution: gagarine commentedIt 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
Comment #11
Everett Zufelt CreditAttribution: Everett Zufelt commented@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
Comment #12
dstol@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.
Comment #13
gagarine CreditAttribution: gagarine commentedOk I get it...
Thanks, you two.
Comment #14
dstolI've just updated the aria branch. It still needs a few tweaks but I'd say it's 90% there.
Comment #15
gagarine CreditAttribution: gagarine commented@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
Comment #16
dstolYeah, probably just a few more tweaks.
Comment #17
dstolOn second glance here, I do think I've worked it out. I'll post a patch once I'm able to this evening.
Comment #18
dstolSorry this took so long to get to you.
Comment #19
gagarine CreditAttribution: gagarine commentedThanks 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.
Comment #20
gagarine CreditAttribution: gagarine commentedFixed thanks to all http://drupal.org/cvs?commit=430738.
I'm very sorry dstol I forget to add a credit in the commit :/.
Comment #21
gagarine CreditAttribution: gagarine commentedComment #22
dstolDon't worry about it, I'm just glad I can help.