Add "autofocus" attribute to the module search

I think we discussed this and related accessibility issues in some other issue... hm. maybe #1919470: Add a search field to the test overview page

+1 for the change and RTBC for me. We are only adding a simple attribute so I don't think it is a feature request.

Code looks good.
Manual testing works correctly.
Testbot likes it.

I'd say this is RTBC!

From a screen reader user point of view this is "won't fix". See the other issue for further details. However, I'm setting this issue to "needs work" to let people discuss about it.

Basically, the issue is that if the cursor is moved to that form field a screen reader user will miss the help text placed at the begin of the modules page and this is of course undesirable.

Code looks good.
Manual-testing suggests code works as-designed.

The help text does not only explain what the search field is used for. So using aria-describedby looks inappropriate to me.

In fact, if I remember correctly, the help text contains links to d.o and various handbook pages... If the search field is auto-focused, even if the text is read aloud because of aria-describedby, a blind user would have to browse the page to find the links and eventually click on them. And browsing a page starting from the middle of it can be really disorienting.

What if we just improve the Title text on the element?

Now: "Enter a part of the module name or description to filter by."
Suggestion: "The module overview can be filtered by entering a part of the module name or its description in this field."

Then we can remove the aria-describedby attribute and still focus on the field.

FYI, this should not go back to RTBC until signoff of a11y team.

" To save time" is not a good justification for bypassing a11y gate. that's a won't fix for me.

Linked related issue.

I've added a question for that here http://webmasters.stackexchange.com/questions/64966/when-is-it-appropria...

I'm trying to find generalized patters for this to help us decide how to move this forward.

Closes I've seen thus far is from Jared stating

Will your users know that there going to a page with a form, and does there need to be any descriptive text you should read before filling out the form? I'm a screen reader user and it can be annoying having focused put in random fields. It's clear why your focus winds up in the Google search box so that doesn't bother me. If my focus were automatically placed in the answer edit field every time I viewed a question on Stackoverflow I would be annoyed since I'd have to force my screen reader to navigate away from the form field and to the top of the page.

Right now the code is:

  <div id="edit-filters" class="table-filter js-show form-wrapper"><div class="form-item form-type-search form-item-text">
      <label for="edit-text">Search</label>
      <input type="search" placeholder="Enter module name" maxlength="128" size="30" value="" name="text" id="edit-text" title="Enter a part of the module name or description to filter by." autocomplete="off" data-table="#system-modules" class="table-filter-text form-search table-filter-text-processed">

      </div>
    </div>

Bruce suggested that aria-describedby could be used to make this more understandable http://www.brucelawson.co.uk/2009/the-accessibility-of-html-5-autofocus/

One of @falcon03's concern was that the help wasn't relevant.

It is really the same issue as per /search/node as well.

There is autofocus in:
/user
/user/password

Applied with:

+    '#attributes' => array(
+      'autofocus' => 'autofocus',
+    ),

But not:
/user/register
/search/node

This was already removed from the javascript, but doing it with HTML5 does allow it to be controlled by the assistive technology.

As @mgifford reported from stack exchange, autofocus should be used only when its obvious what a certain field should be used for and that field is the most important element of a page. That's not the case of the search field on the admin modules page, though.

Mike suggested that using HTML 5 autofocus attribute AT can be configured to not use it.
Offering a pleasant user experience to AT users is responsibility of a website, not of a screen reader. Not to mention the fact that there are certain situations where you could find autofocus useful, even if you use a screen reader. And I could easily suppose that enabling/disabling autofocus support from the screen reader configuration could just be a global flag, so you couldn't fine-tune autofocus support to your needs. Long story short, from a screen reader user point of view let's close this issue as won't fix...

Let's kill it.

Tags...
- Tidying up the "needs accessibility review" list
- Gathering issues which requested autofocus