🧪 ⚗️ 🚧 Proof of concept to abstract the rules logic 🚧 #429
Conversation
accessibility-checker.php
Outdated
| /** | ||
| * Include Rules | ||
| */ | ||
| require_once plugin_dir_path( __FILE__ ) . 'includes/classes/class-rules.php'; | ||
| require_once plugin_dir_path( __FILE__ ) . 'includes/classes/rules/class-rule.php'; | ||
| require_once plugin_dir_path( __FILE__ ) . 'includes/classes/rules/class-rule-aria-hidden.php'; | ||
| ( new EDAC\Rules() )->add_rule( 'aria_hidden', new EDAC\Rules\Rule_Aria_Hidden() ); | ||
| add_filter( | ||
| 'edac_filter_register_rules', | ||
| function ( $rules ) { | ||
| $rules_from_objects = ( new EDAC\Rules() )->get_rules(); | ||
| foreach ( $rules_from_objects as $rule ) { | ||
| $rules[] = array( | ||
| 'title' => $rule->get_title(), | ||
| 'info_url' => $rule->get_info_url(), | ||
| 'slug' => $rule->get_slug(), | ||
| 'rule_type' => $rule->get_type(), | ||
| 'summary' => $rule->get_summary(), | ||
| ); | ||
| } | ||
| return $rules; | ||
| } | ||
| ); | ||
|
|
There was a problem hiding this comment.
This is just for the POC, to show how we can add rules in a manner that is backwards-compatible.
| $rule_file_path = plugin_dir_path( __FILE__ ) . 'includes/rules/' . $rule['slug'] . '.php'; | ||
| if ( ! file_exists( $rule_file_path ) ) { | ||
| continue; | ||
| } |
There was a problem hiding this comment.
This was done simply because I removed the aria_hidden rule file
|
@aristath have you looked at how the rules are changing with the transition to JavaScript scanning? https://github.com/equalizedigital/accessibility-checker/tree/feature/javascript-scan |
|
@amberhinds thank you, I had not seen that! |
|
Hi @aristath, thanks for the code cleanup help! Here's an overview of how checks are running in the editor: |
|
@aristath, see the readme @boonedev posted for details. Currently, the only rule converted to Javascript is the color contrast as it was the rule causing the most false positives. We'll have a hybrid approach until all rules are converted over using either axe-core or a custom Javascript rule. So we'll still need to refactor the rules logic as you've demonstrated. Unless we push forward and convert all the rules now. |
This PR is just a prototype to investigate how we could abstract the logic for rules in a more object-oriented way.
Please note that there are some modifications where we include the files and run the evaluations to allow running both the old and new implementations for the sake of this experiment/POC, showcasing how we could do it. I'm also hard-including the new classes because I'm treating this as a rough proof of concept to demonstrate an idea 😅
What is your opinion on doing something like this @boonedev @jdevalk @SteveJonesDev ?
Right now we have some basic data for rules in the
includes/rules.phpfile, and then we have the rule's evaluation inincludes/rules/{RULE_SLUG}.phpfiles. This PR attempts to do the following:Rulesobject, which can act as a collection of rules.Ruleobject, which individual rules can extendRule_Aria_Hiddenas a demostration of how a rule can be implemented, extending theRuleobject. This class unifies the rule info fromincludes/rules.phpandincludes/rules/aria_hidden.phpincludes/rules/aria_hidden.phpfile since the info is now in theRule_Aria_Hiddenobject, and removes the rule fromincludes/rules.php