Some user usability and accessibility problems (grouped report to split)

AS: Sorry for the grouped report, but I don't know Drupal much (and I'm not using it myself, except, occasionally, on some other people's websites), don't have enough time to search for existing reports, and post separate reports. If some issues are not already tracked, please create separate reports (do not reply here, as it would make tracking hard), post the link here (there does not seem to be a dependency feature in Drupal issue tracking...?), and close this one when all problems which are not previously reported, have been reported as a separate report.

Here are a few usability and accessibility problems I just encountered (taking into account that some might be separated into multiple reports):

1. When registering to drupal.org, the registration confirmation message was displayed nearly in the middle of the page (below the header, and some generic content). It makes it hard to spot it (notably because the homepage features many colors -which generally is a problem, as color loses all meaning (if you have a red block, I probably won't see it as anything problematic, if I see a green block, I probably won't see it as any kind of confirmation -by the way, the confirmation message was in a blue block, if I remember correctly... it should be in a green block, as any confirmation message)). The messages should be shown nearer to the top of the page, if not at the very first element of the page. Also, I didn't check the source code, but the messages must be the very first elements of the source code, in the page body, to permit blind people to get the messages immediately, after the page has been loaded.
2. When registering to drupal.org, I couldn't set a password in the registration form. If it was to send be a permanent generic password by email, it would be quite alright (although, indeed, a possible security issue), but the password is only temporary. It means I have to fill two different forms to register (well, the second one is the full user profile, but it is still considered to be a separate form, and as I must at least fill the password, it counts as a second form being required to register, which is a problem). I didn't check, but if you don't fill the password, can you use you account, and see it deactivated after a day, like the password validity end date meant? While I guess you can simply reactivate it by email, it will probably annoy people who are in a hurry. You should really permit people to set their password in the first form (as not being able to set it in the first form is not any kind of shortcut for the user -it really adds to the time required to register-, this is really bad usability -and bad accessibility, as it complexify registering, and might cause access problems to some people). If you are using this to push people to fill their user profile, after having registered, you should better simply redirect them to their user profile, when they login their first time (I mean, without requiring them to fill anything -and this should be specified in an informational message, saying something like "Welcome to our website, and thanks for registering. For your first-time login, you have been redirected to your user profile. You might want to check it, and, optionally, update it." -note you also should add a link back to the page the user logged in, if it was not a dedicated page).
3. When posting something, "abbr" and "acronym" tags are not listed as being allowed. I didn't test if they were only undocumented, but they should be supported *and* listed.
4. The drupal.org website is quite slow... I have no idea if this is a local problem, or a temporary problem, but if this is a regular problem, you might want to ask the community for donations for new servers and/or more bandwidth (if you didn't already -again, I didn't check, and don't know much about Drupal).
5. When I get to http://drupal.org/project/issues/user_experience (and it probably concerns other similar pages), there is no free-text search field in the main search form (similarly to SourceForge, where you can only search in the report title, from the main search form). This is a usability problem. I am generally tempted to search in the search box in the drupal.org header, but this is a global search box. The "Advanced search" link is not visible enough (it should be somewhere near the "Search" button, if you don't want to include a free-text search field, in the main form -if you do, there is no problem with leaving it where it is, and it should probably be left here).
6. In http://drupal.org/project/issues/search/user_experience (again, it probably concerns other pages -issue reporting for other categories of issues), it is annoying to have to select all statuses, by hand, when the select box is not large enough (you should at least, list seven elements -you can shrink the select box, if there are less items, and you should make it even larger, if it is commonly used, like the status select box, notably if all items would then fit, without it being too large (there are probably too many items in the status select box, however, so you should keep it at seven)). Also, as with bugzilla, you default only to active and fixed reports, which means most users will have to select all items each time, to search for duplicates. It generally means that a lot of duplicate reports will be posted, because most people don't get how search works, and the default value is counter-intuitive (when you get to a search form, except in specific cases -followed a link which said "search in this or that specific category"-, the default values should permit searching all data supported by the form, except, possibly, in very specific cases, or, possibly, if you warn the user about it, and tell him how to search all data, although this does complexify things a bit, and some users will still don't quite get it -I understand the server load problem, but this should never be a reason to lower usability and accessibility).
7. In http://drupal.org/project/issues/search/user_experience (again, certainly in other places), with the default theme (and possibly with other themes, I don't know), you use a circle, in free-text input fields... if they were drop-down select fields, I would argue that a circle is not an arrow, and when you mean a drop-down select box, having a downward arrow is quite fondamental, but this is not even the case... you should remove these circles, which are misleading. It seems you use it as a status notification icon, when doing completion... you should not. It is disturbing (even more, because the completion is slow, probably because the whole website is). If you really want to keep it, put it outside the input field... (as there are other fields on the same row, you should put it near the label, on the above row).
8. In http://drupal.org/node/add/project-issue the list of projects is far too long, with far too many similar names (modules, notably). Also, when I chose "Drupal project => User experience", I was directly led to the main issue submission form... are there projects which lead to other intermediary steps? if not, there shouldn't be an intermediary step at all. For the select length issue, you should split the list in some way or another (taking into account that having select boxes which are updated with JavaScript, depending on other select boxes, sure are an accessibility problem... -for users who use a browser without JavaScript, or with it being deactivated, and for blind users who use a JavaScript-enabled browser (most do, as assistive technologies generally use MSIE or Firefox, as a base)... you could use the new trick to notice assistive technologies that the page content has changed -check accessibility websites talking about AJAX-, but this is far from being optimal). I currently do not have any solution for this, except using intermediary steps, but this is not always possible, and it does make the form filling process longer for most users... (which generally is not a problem for users who seldom use the form, but a significant problem for users using it everyday). You should also find a way to describe the many entries, a bit, notably modules with similar or ambiguous names (it would however mean too much content in the select box, so another way should be found... -again, thinking about accessibility).
9. In some forms (the registration form, I think I remember, and the issue reporting form -like for file attachments), the field description is displayed (and printed in the source code) below the field. While it's not too bad, for users who can *see* the page, when it is an help information, and not a real description (like with the "Description" textarea field -it would also probably put the description textarea field too low in the page, in the help for this field were put above it), it is quite problematic for users who cannot see the page globally, and read it linearly, using some assistive technology. You should always put it above the field, in the source code (and be sure to identify which field the description is associated to -the best way to do it is to use per-field fieldsets (note you can include fieldsets in other fieldsets, to group them), and using the legend element to identify which field we are talking about... (also note that you can of course hide these additional fieldsets borders and legend, with CSS, so it should not change anything as far as CSS design is concerned)). When the description is really a description (the file attachment field, in the issue reporting form, for example), it should also be put above for sighted users (in the case of file attachments, you can easily use a visible fieldset, so the description is properly associated to the field).