Improve a11y for the search feature #886

Merged
merged 4 commits into from Sep 2, 2015

Conversation

Projects
None yet
2 participants
@mfairchild365
Member

mfairchild365 commented Sep 2, 2015

This does two things to improve a11y for the search feature.

  1. fixes #885 - Pressing escape will close the results pane. This could be further improved by adding a link to close the results pane (but I'm not sure exactly how the would look).
  2. Send focus to the results pane on manual submit (not autocomplete)

Note that an update to the search application will have to be rolled out at the same time. There is a paired PR for that project which I will submit in just a second.

mfairchild365 added some commits Sep 2, 2015

A11y: send focus to the results frame
This will send focus to the results frame if the form is manually submitted (via enter key or submit button)
wdn/templates_4.0/scripts/search.js
+
+ //Close search on escape
+ $(document).on('keydown', function(e) {
+ if (!e.keyCode || e.keyCode === 27) {

This comment has been minimized.

@kabel

kabel Sep 2, 2015

Contributor

!e.keyCode ? What is that catching? Seems like this condition might catch more than it should.

@kabel

kabel Sep 2, 2015

Contributor

!e.keyCode ? What is that catching? Seems like this condition might catch more than it should.

This comment has been minimized.

@mfairchild365

mfairchild365 Sep 2, 2015

Member

Good question. I saw it referenced in a few examples and thought I'd try to find a case where it was helpful. I couldn't find a good case for it and forgot to take it out.

@mfairchild365

mfairchild365 Sep 2, 2015

Member

Good question. I saw it referenced in a few examples and thought I'd try to find a case where it was helpful. I couldn't find a good case for it and forgot to take it out.

@@ -151,15 +156,49 @@ define(['jquery', 'wdn', 'require', 'modernizr', 'navigation'], function($, WDN,
if (postReady && $unlSearch[0].contentWindow.postMessage) {
e.preventDefault();
$unlSearch[0].contentWindow.postMessage(domQ.val(), searchOrigin);
+ if ('auto' != source) {

This comment has been minimized.

@kabel

kabel Sep 2, 2015

Contributor

Just FYI, using type-strict comparisons ( === , !== ) are generally encouraged for performance and to avoid logical accidents.

@kabel

kabel Sep 2, 2015

Contributor

Just FYI, using type-strict comparisons ( === , !== ) are generally encouraged for performance and to avoid logical accidents.

This comment has been minimized.

@mfairchild365

mfairchild365 Sep 2, 2015

Member

Good point

@mfairchild365

mfairchild365 Sep 2, 2015

Member

Good point

@mfairchild365

This comment has been minimized.

Show comment
Hide comment
@mfairchild365

mfairchild365 Sep 2, 2015

Member

@kabel one question that I had: what is the best way to handle adding event listeners to DOM elements in a framework environment?

For example, in this PR I have:

$(window).on('message', function(e) {

Now, I could see legitimate cases where developers who use the framework might want to listen for their own iframe postMessage events in the same way. What is the best way to ensure that our event handler is not ignored, and that it does not affect other event handlers?

Member

mfairchild365 commented Sep 2, 2015

@kabel one question that I had: what is the best way to handle adding event listeners to DOM elements in a framework environment?

For example, in this PR I have:

$(window).on('message', function(e) {

Now, I could see legitimate cases where developers who use the framework might want to listen for their own iframe postMessage events in the same way. What is the best way to ensure that our event handler is not ignored, and that it does not affect other event handlers?

@kabel

This comment has been minimized.

Show comment
Hide comment
@kabel

kabel Sep 2, 2015

Contributor

Strictly speaking there is nothing we can do to prevent other developers from adding additional event listeners for the postMessage event (or removing, blocking this listener, for that matter). However, I believe the new handlers that are added are executed in the order that they were added. So as long as long an earlier handler did not stop the event propagation, multiple handlers should lovingly coexist.

Contributor

kabel commented Sep 2, 2015

Strictly speaking there is nothing we can do to prevent other developers from adding additional event listeners for the postMessage event (or removing, blocking this listener, for that matter). However, I believe the new handlers that are added are executed in the order that they were added. So as long as long an earlier handler did not stop the event propagation, multiple handlers should lovingly coexist.

kabel added a commit that referenced this pull request Sep 2, 2015

Merge pull request #886 from mfairchild365/search-a11y
Improve a11y for the search feature

@kabel kabel merged commit 45f5275 into unl:develop Sep 2, 2015

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment