Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.The javascript trick might save many users one click, but without also having a submit button, the html form is broken and it is totally nonfunctional and not accessible for other users.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | accessible_nodeformbutton_hide-807016-6.patch | 2.24 KB | c-logemann |
| #2 | accessible_nodeformbutton_hide-807016-2.patch | 1.83 KB | c-logemann |
Comments
Comment #1
c-logemannI just found the same problem by testing this module for my customer.
This a very bad accessibility situation.
Currently there is a hard coded "display: none;" CSS style in the form.
There should be an admin option and a fallback strategy for users without JS.
I will provide a patch as soon as possible.
Comment #2
c-logemannPatch with an option to disable the hiding of the button.
The hiding itself is now realised with a javascript that adds the accesible system class "element-invisible" to the next button in the node form.
This is currently for drupal 7 and can be backported if someone is interrested in.
Comment #3
mgiffordAny reason not to use
'#title_display' => 'invisible',as per:http://api.drupal.org/api/drupal/developer!topics!forms_api_reference.ht...
Comment #4
c-logemann1. #title_display may help to be accessible with screenreaders but the problem is also with browsers without available javascript.
2. #title_display is for hiding the title of a form element but not for hiding a button.
Comment #5
mgiffordGood reasons. Although other than Lynx, what browser doesn't come with Javascript?
I can see that some individuals (or possibly institutions) might turn off Javascript, but the vast majority of screen-readers operate on the DOM & so it's not not a problem.
So you need to hide the entire checkbox I assume.
Comment #6
c-logemannUpdated patch. The new JS-File was missing.
> So you need to hide the entire checkbox I assume.
How do you mean this? My patch is adding a system CSS class with JS to the button element which is for hiding in screen reader compatible way.
And because of JS this solution is working when JS is off or not available.
I think talking about majorities is not good especially when it's easy to help lot's of minority users. The drupal core itself and many contrib modules I know are working without JS. They are just doing only a progressive enhancement with javascript and that is a good strategy in my opinion and one of the reasons why I love drupal.
#edit: Additional Informations about "Accessibility best practices" and especially the class "element-invisible".
Comment #7
mgiffordI do totally agree with progressive enhancement as an approach. That being said, javascript doesn't cause accessibility issues like it once did.
I've had no need to use this module. I don't have an example where this is used. To test the patch and what it does I need to replicate it. I've just scanned the code and am providing comments.
I was a bit surprised to see that the accessibility best practices documentation wasn't one that I'd edited. I've been involved with most. @Everett Zufelt's done a great job describing the CSS class element-invisible. I was definitely slogging along on that issue queue with him. Quite familiar with it.
Anyways, I'm not saying that your approach is wrong. I'm just asking questions & based on scanning the code.
I'm pretty much always in favour of nixing 'display: none;' for something else.
Comment #8
c-logemann@mgifford: Yes maybe the JS Problems are reduced because of modern screen readers but I think we should be as accessible as possible especially if it's easy to be.
For everyone who wants to help testing: Just install the module in a test drupal system and activate. There will be a new node type "biblio". Try to create biblio nodes with and without activated JS with and without my patch.
Comment #9
rjerome commentedI've committed the patch in #6
http://drupalcode.org/project/biblio.git/commit/fb0a768