I can see some problems/shortcomings in Drupal’s forms that I really should fix before putting a site up. The main issues include:
No ARIA attributes to link error messages with inputs (particularly bad considering how far apart they can be in the complex HTML)
Instructional text inside the form tags (should be outside)
On errors, nothing changes to explain the reload (e.g. page title)
Option to send a copy e-mail (just asking for abuse)
Now this is the point at which I’ve found the first major shortcoming in Drupal (aside from the existence of these problems in the first place): there is no easy/obvious way to fix them.
Now, I realise that I might be sailing out onto rough seas here, perhaps in the form of the Drupal API, but what is the best route for me to sort these issues?
Ahhhh, you’ve come to the right place although the way SitePoint’s arranged the forum, I’m surprised you actually got here
Anyway, I’m not sure I understand all of the issues and concerns. At first I thought you were creating your own forms and then wanted to modify them to cover your points but that can’t be the case because the webform module which is the recommended method for creating forms includes all of the items you’ve touched on. They aren’t strictly adherent to ARIA but there is an attempt at accessibility.
Are you talking about Drupal’s built in forms for logging in and creating memberships, etc. Oh, also… What version of Drupal are you working with?
Hi Andrew. Yeah, it’s the default forms that are problem: specifically, the site contact form and the comments forms. They are not how I would code a form and they are just not up to current standards, which is surprising and disappointing. Added to the accessibility issues is the apparent lack of an option to remove the copy e-mail function, which is open to abuse.
Ok, that’s what I figured. So it’s the site-wide and user Contact forms that ship with Drupal that you’re using. Personally I haven’t used the built in Contact form since Drupal 5 because I found the WebForm module so much more flexible/Capable however I see some pretty nifty functionality in the OEM Contact form and particularly the user contact forms.
There was a discussion back in about 2006 regarding “copy” spam abuse and the response was to only show the copy checkbox to logged in visitors. The copy checkbox will not show up for anonymous users so the only way someone could abuse it would be to log in. If this should occur you have a record of who was doing the abuse so you can kick them from the website and ban their IP if need be.
Of course the user-wide contact form should only be open to logged in visitors via the permissions page so again you have a good record of who is abusing it if that should occur.
As far as alerting users that they haven’t filled in fields, the system does provide a fairly health warning when the page refreshes that various fields haven’t been filled in a container called “messages” and the fields are highlighted.
Thanks for replying, Andrew. I’ll look into the webform module that you mentioned. Regarding the error messages, their implementation is poor because there is nothing to tie each message to applicable inputs and/or allow AT users to move directly back and forth between the error messages and the inputs. This ability is very important and ARIA achieves it. Added to that, ARIA live can alert the user to the changed content and let him go there directly. Bascially, the error messages are just text in a div with no meaning to ATs. Prior to ARIA, AT-minded developers would incorporate the error messages as modified form label text and change the page title to something like Errors in Form Data. And non-form block-level elements inside forms are ignored by most ATs when they switch to form mode, which is why instructions should always be above a form in the HTML.
If I want to modify or completely replace a form, or any other HTML block for that matter, what would be the best/easiest/most effective method? Should I learn how to use the API? (If it can do that). Learn how to write my own modules and use them as replacements? Edit the core source code somewhere? (Not very maintainable, I know, but a bit nearer to my comfort zone).
I want to stick with Drupal if possible, but its lack of easy and full control over all HTML output is a frustrating drawback.
I would suggest that you learn the API. It is quite massive but the online reference is decent now (still lots of holes in the D7 online reference though). There are also a lot of books that will get your feet wet. I would get “Drupal Pro Development”. There is a recent printing that deals with D7. I got a copy when they put it out for D6 and found it very informative about how to use Drupal correctly (ie: don’t hack the core).
If you really want to customize the form fields, the right way (in my mind) is to create a helper module that works with Drupal’s forms and exposes the form fields in some sort of admin page so that you can do whatever you need to do as far as adding attributes or hooking error messages to their fields. This isn’t trivial but it’s not impossible and someone may be working on a solution already within one of the ARIA discussions.
For an interim solution you might be able to get some better results via jQuery’s validate plugin. It will add a level of validation on the client side that won’t allow the form to submit until all of the required fields are filled and the error message will be right beside the field in question.
I’ve looked at some Drupal books, but I’m not sure specifically about Pro Drupal: it looked like a good bet, but has poor reviews for the most recent edition. I was considering The Definitive Guide instead (same publisher). I’ve been studying a lot of the module files and theme templates tonight, largely for my own education, and I got as far as building a modified comment module that has a few small changes (e.g. a note about moderation delay; removal of automatic title).
I’ll try to make an interim solution for ARIA describedby that will use JS to insert them when errors occur. The JS will be fairly easy, but I still need to figure out how to get IDs onto the error messages.
Wow… Mental note, never use the Quick reply box for a quick reply. This is the second time I’ve replied to a thread with a fairly length reply and it has disappeared into the ether when I submitted.
So, yes I have looked at the OEM message and it doesn’t reference the ID of the offending field but it does reference the name of the field. I am quite sure that the error message uses the Name of the field and just capitalizes it in the message which means you can with some certainty grab the word in front of " field is required", string-to-lower-case it and that is the name of the offending field.
Failing that, you can suppress the OEM message and create your own with jQuery. jQuery comes with Drupal so it’s a good way to go and you can use Drupal’s API to inject JS into the header with druapl_add_js(); http://api.drupal.org/api/drupal/includes--common.inc/function/drupal_add_js/7 (I sue this all the time).
