Problem/Motivation

When you visit the module page you want to enable a module or you want to search for a module. To save time the "Enter module name" field should be focused.

Proposed resolution

Just add the "autofocus" attribute to the field.

User interface changes

The user can see that the field is focused automatically.

Screen Shot 2013-09-24 at 00.30.08.png

#1848064: Allow to filter modules by arbitrary search strings on the Modules page

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

yannickoo’s picture

Status: Active » Needs review
FileSize
663 bytes
yannickoo’s picture

Let's check whether it is okay for screenreaders to focus on that field.

YesCT’s picture

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

jibran’s picture

Category: feature » task

+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.

mparker17’s picture

Status: Needs review » Reviewed & tested by the community

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

I'd say this is RTBC!

yannickoo’s picture

Oh, YesCT was right and this was removed in #1932958: Cursor shouldn't be moved to module search field.

Let's discuss in the other issue because we have to figure out how we can make it easier for blind people.

falcon03’s picture

Status: Reviewed & tested by the community » Needs work

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.

yannickoo’s picture

Status: Needs work » Needs review
FileSize
819 bytes

I talked with jessebeach and she showed me the aria-describedby attribute and I think it is a good solution to have the help text included.

mparker17’s picture

Status: Needs review » Reviewed & tested by the community

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

falcon03’s picture

Status: Reviewed & tested by the community » Needs work

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.

BarisW’s picture

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.

Bojhan’s picture

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

nod_’s picture

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

BarisW’s picture

Status: Needs work » Needs review
BarisW’s picture

Issue summary: View changes

Linked related issue.

mgifford’s picture

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.

mgifford’s picture

There is autofocus in:
/user
/user/password

Applied with:

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

But not:
/user/register
/search/node

mgifford’s picture

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

falcon03’s picture

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...

nod_’s picture

Status: Needs review » Closed (won't fix)

Let's kill it.

andrewmacpherson’s picture

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