ucf / ucf-resource-search-plugin Goto Github PK

We get flagged in SiteImprove on pages where a resource search is included on the page with nav filters, due to each nav filter link linking out to page anchors that don't actually exist on the page.

Local link destination does not exist
1.3.1 Info and Relationships
Description of this issue:
A local link (anchor link) occurs but the destination does not exist.
How to fix it:
When using local links they must refer to an existing element on the page.

We need to update how these filter links work in a way to resolve the issue above. Maybe using <button>s instead of <a>s for each filter link would be a good place to start?

Warning: call_user_func_array() expects parameter 1 to be a valid callback, class 'UCF_Resource_Link_PostType' does not have a method 'add_resource_link_types_fields' in /wordpress/wp-includes/class-wp-hook.php on line 286

Looks like these actions are getting registered referencing the wrong class name (should be add_action( '...', array( 'UCF_Resource_Link_Type', '...' ) instead of add_action( '...', array( 'UCF_Resource_Link_PostType', '...' ):
https://github.com/UCF/UCF-Resource-Search-Plugin/blob/master/includes/ucf-resource-link-tax.php#L14-L17

Description
See title.

Why it's Important
Underlines were added to all links by default in Athena v1.1.1 and can look a bit messy on certain components/layouts.

Alternatives
n/a

Possible Implementation
Remove underlines; test removal of underlines against accessibility scanners

Additional context
See the A-Z index on ucf.edu as an example.

<article> is probably not the most appropriate tag to surround the resource search + its contents, and it also conflicts with most of our themes that include a single wrapper <article> around page/post content and don't include a unique aria-label for it.

Strict Standards: Non-static method UCF_Resource_Link_PostType::get_labels() should not be called statically in /wordpress/wp-content/plugins/UCF-Resource-Search/includes/ucf-resource-link-posttype.php on line 15

Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method UCF_Resource_Search_Common::enqueue_styles() should not be called statically in /wordpress/wp-includes/class-wp-hook.php on line 298

Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method UCF_Resource_Search_Common::enqueue_scripts() should not be called statically in /wordpress/wp-includes/class-wp-hook.php on line 298

Need to enforce an expected default value of true when calling get_option() here; otherwise it'll return empty if the user hasn't force-saved the plugin options at least once.

Description

See title; inline JS used to initialize PostTypeSearchDataManager should be moved to the document footer (currently it's printed in a <script> manually in the "classic" layout)

Why it's Important

To allow jQuery to be loaded in the document footer, and better ensure it's available when the resource search JS needs to run.

Alternatives

n/a

Possible Implementation

1. Use wp_add_inline_script( 'ucf-resource_search_js', $string ) instead of prepending $string to the rest of the layout markup.
2. Update null to array( 'jquery' ) on the line below to ensure ucf-resource_search_js is registered with jquery as a dependency:

Additional context

n/a

Data is read from window.location.hash and passed to $() via the following statements:

var t=window.location.hash;
$("." + t)

https://cwe.mitre.org/data/definitions/79.html

The search form that gets generated for the main resource search feature doesn't include a submit button; we get flagged in Site Improve for every page/instance where this occurs.

We'll need to either:

• Implement an actual submit button that forces results to be present on submit
• Or, ensure we're meeting "change of context" requirements as necessary to meet WCAG 2.0 requirements

More info
https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/G13
https://www.w3.org/TR/WCAG20-TECHS/H32.html