[wp-meta] [Making WordPress.org] #2753: Plugin directory search sorting and filtering

[Making WordPress.org]

#2753: Plugin directory search sorting and filtering
-------------------------------------+-------------------------------------
 Reporter:  tellyworth               |       Owner:
     Type:  enhancement              |      Status:  new
 Priority:  normal                   |   Milestone:  Plugin Directory v3 -
Component:  Plugin Directory         |  Future
 Keywords:  needs-design has-ui-     |  Resolution:
  feedback needs-screenshots         |
-------------------------------------+-------------------------------------

Comment (by afercia):

 A few accessibility considerations, not pretending to be an exhaustive
 list of potential issues to address:

 '''Sidebar:'''
 If it's going to be a fixed sidebar, I see no a11y concerns. Instead, if
 it's going to be a "sliding" sidebar, it's highly preferable it is placed
 in the source right after the toggle button that opens it. This way, it
 would be in the natural tab order. Otherwise, focus needs to be managed.

 '''"Sort by" select:'''
 It should have a button to submit, see
 https://core.trac.wordpress.org/ticket/40925

 '''Interaction:'''
 > One is that each choice is a link (parameterized search) so the page
 reloads on each. The other is that it is a form that you set all the
 parameters and then submit once.
 Checkboxes and a submit button are highly preferable. Triggering a search
 when checking a checkbox produces an unexpected change of context though.
 Depending on the implementation, there's also the risk the search fails to
 return the intended results and the risk to hammer the server with
 multiple requests. For example, quickly checking and unchecking multiple
 checkboxes can easily fail.
 To reproduce on the http://gibrown.wpsandbox.me/main/?s=post example, just
 quickly check and uncheck `dowork` with a double click. Although you've
 left the checkbox unchecked, the search triggers after the first action
 and you get results for dowork `tag=dowork`.
 Ideally, a submit button should always be used, as that's the only
 reliable way to confirm the users intention to submit.

 '''Checkboxes:'''
 Consider to group them in a fieldset with a legend and in this case the
 headings can be removed.
 Note: for inspiration, see the themes filtering in core, which has been
 changed to use fieldsets/legends (no headings) together with some more
 a11y improvements (e.g. buttons are now buttons and not links `<a class
 ="drawer-toggle" href="#">`, the submit button is now also at the end of
 the form, etc. see https://core.trac.wordpress.org/changeset/38640).
 Instead, the themes directory hasn't been updated with this changes.
 If keeping the headings, the heading hierarchy in the page should be
 correct. Currently, on http://gibrown.wpsandbox.me/main/?s=post I see the
 headings are h4 and they skip a few levels.

 '''Labeling:'''
 - Checkboxes should have an explicitly associated label with for/id
 attributes, as some browser / assistive technologies combinations,
 especially some old ones, don't understand wrapping (implicit) labels. See
 https://make.wordpress.org/core/handbook/best-practices/coding-standards
 /accessibility-coding-standards/#labeling
 - All form controls should have a visible label
 - Don't use placeholders as replacements for labels, see
 https://core.trac.wordpress.org/ticket/40331

 '''Search as you type:'''
 Note: I'm not taking into considerations the mentioned "search as you
 type" UI, as it seems it's not going to be implemented for now. However,
 please consider this kind of UI needs a considerable amount of work to get
 a minimum level of accessibility and I'm not sure they can be made "fully"
 accessible. For the similar searches in core, some concerns have been
 expressed about their real usability, see for example
 https://core.trac.wordpress.org/ticket/31818 and
 https://core.trac.wordpress.org/ticket/38211
 Also worth considering the following WCAG Success Criterion about
 keystrokes timings: https://www.w3.org/TR/WCAG21/#keyboard
 > All functionality of the content is operable through a keyboard
 interface without requiring specific timings for individual keystrokes ...

--
Ticket URL: <https://meta.trac.wordpress.org/ticket/2753#comment:26>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org