Dashboard prints the search form title twice on the page (can confuse screen reader users)

It's possible this patch will address that problem:

http://drupal.org/node/718922#comment-2995514

We are looking to get a review to get element-invisible modified for other reasons, but it might address this problem.

It's possible this patch will address that problem:

http://drupal.org/node/718922#comment-2995514

We are looking to get a review to get element-invisible modified for other reasons, but it might address this problem.

Please test the latest patch in this issue:
#718922: system class: .element-invisible does not work with VoiceOver on OS X Snow Leopard

Marking this as duplicate, since it addresses the same problem (hiding an element safely while keeping it accessible for screen readers).

Not sure what this issue has to do with the overlay. This bug appears in the dashboard whenever Seven is your theme; doesn't matter if it's in the overlay or not.

I confirmed that the patch at #718922: system class: .element-invisible does not work with VoiceOver on OS X Snow Leopard solves this but I'm reopening it anyway because this is really an independent bug that could presumably be solved on its own. The offending code looks like this (in Seven's style.css):

#dashboard div.block h2 {
  margin: 0;
  font-size: 1em;
  padding: 3px 9px 3px 19px;
}

Randomly sticking padding on all <h2>s in the dashboard regardless of their purpose sounds like it might be a case of bad CSS (or possibly bad underlying HTML) to me :)

David, this appears in every theme using .element-invisible.
Not seven specific...

The latest patch in #718922: system class: .element-invisible does not work with VoiceOver on OS X Snow Leopard works great for all themes. Setting this back to Duplicate.

No, this issue does not appear in Garland or Stark - only Seven.

It results most immediately from the CSS pasted above (in particular, the padding). The padding exists to target the dashboard block headings, but it gets the element-invisible heading too since it is also an h2. The CSS is not at fault, but rather the HTML structure is; we should not have an h2 within an h2 on the dashboard. #718922: system class: .element-invisible does not work with VoiceOver on OS X Snow Leopard solves the visual problem and is a good idea in general, but does not solve the underlying bug that causes this specific case.

The fundamental problem that causes this is actually that the dashboard is printing the default block title ("Search form", enclosed in <h2>) twice on the page, once visually and once with element-invisible. This does not make sense; the element-invisible one should not even be there. The search module has code (see search-block-form.tpl.php) to prevent this:

  <?php if (empty($variables['form']['#block']->title)) : ?>
    <h2 class="element-invisible"><?php print t('Search form'); ?></h2>
  <?php endif; ?>

but apparently that is not working correctly on the dashboard. I think this is the fault of the Dashboard, not the Search module, but not positive, and don't have time to research it further at the moment :)

Screen-readers don't get confused, but their users can :)

Also, I agree that this issue should be fixed, but it isn't a major accessibility issue.

I just tried to find the weird gray box in Seven with FF, Safari & Chrome - I didn't see it. I attached a screenshot of one.

I'm not sure if I'm missing something here, but this might be fixed already in core.

#718922: system class: .element-invisible does not work with VoiceOver on OS X Snow Leopard fixed the visual problem but david is suggesting there is a deeper underlying cause for this. That is why this is till open.

Ok, so I did some poking around on this issue. Initially looking at the dashboard_page_build() function in modules/dashboard/dashboard.module

However I think it's down to line 37 of modules/search/search-block-form.tpl.php

 <?php if (empty($variables['form']['#block']->title)) : ?>

Is there a different variable for the dashboard?

Ok, think this addresses this issue.

#13: 821646-1.patch queued for re-testing.

#13: 821646-1.patch queued for re-testing.

Hmm.. reroll? :)

Arg.. Re-roll.. This is a simple, but annoying problem. The attached image demonstrates that the problem is gone in this patch.

Pretty sure the display bug is gone now - so this is only a screen reader issue.

Regarding the patch, what happens when the block is in a different dashboard region?

How about this patch?

As far as I can tell, the search module's template file is simply checking the wrong variable. If we fix that, the problem goes away :)

I tried this patch with the block both inside/outside the dashboard and both with/without a custom title, and in all cases it seemed to work correctly (exactly one <h2> associated with the block, visible to all users when it should be and only to screen readers otherwise).

Ok, so in testing this now I couldn't find the search box within my dashboard:

http://drupal7.dev.openconcept.ca/#overlay=admin/dashboard/configure

I'm getting a cold so perhaps I'm missing something, but I should be able to just add that block, right?

Where is the list of blocks available to the dashboard defined?

Dashboard blocks are those labeled 'administrative' in hook_block_info(). The search block isn't one of them, but the standard install profile puts it on the dashboard anyway. But if you didn't start from that it won't be on there.

You can still get to it via the "Add other blocks" link on the dashboard, though (assuming it's not being used elsewhere in the same theme).

Different issue, basically :)

I've applied this in another context and it works fine. It's a trivial change but improves markup.

@David thanks for finding the simpler solution!

Committed to CVS HEAD. Thanks.