According to w3..

• Prepared statements reduce parsing time as the preparation on the query is done only once (although the statement is executed multiple times)
• Bound parameters minimize bandwidth to the server as you need send only the parameters each time, and not the whole query
• Prepared statements are very useful against SQL injections, because parameter values, which are transmitted later using a different protocol, need not be correctly escaped. If the original statement template is not derived from external input, SQL injection cannot occur.

Thanks @jrchamp!

From #32, I see that users think user errors are system errors.

User errors should be displayed in a different way to avoid this confusion.

Currently, the app uses default Bootstrap colors and settings.

Once features are set, a custom branding system would establish our brand.

As per the AGPL, this text need to appear in the source file:

Equalify is a platformed developed to integrate various services that manage websites.

Copyright (C) 2022 Blake Bertuccelli

This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Affero General Public License for more details.

You should have received a copy of the GNU Affero General Public License along with this program.  If not, see <https://www.gnu.org/licenses/>.

The Sites interface is fine for a small number of sites, but what happens if you have hundreds, or thousands? You probably need an option for a list view (like a toggle between tile or list), and a search box. Maybe some kind of grouping too?

Nope! We enforce WCAG standards through deep integrations with your site's content management systems. For instance, we can email site owners with WCAG errors. Testing services without Equalify's deep integration cannot do that.

We plan to offer lots more WebOps integrations. You'll be able to manage every aspect of every website in your network.

Integrations currently hook into scans by creating a function with _scans appended to the function name (ie- wave_scans()).

That limits the possibilities of integrations.

Why not develop a hook/event system that allowed integrations to update every aspect of Equalify?

I am a fan of how the WordPress hook/filter/action system works.

In a gist, I can hook onto any function by adding the action to my new function.

That would allow any integration to do things like update the main content of Equalify with something like this:

function sample_function(){
  return 'hello world';
}
add_action( 'sample_action', 'sample_function');

That code would return 'hello world' wherever sample_action() was run.

I imagine we would need to refactor much of the codebase to follow the observer pattern.

Coding standards haven't been developed yet.

So far these standards were suggested:

• https://github.com/FriendsOfPHP/PHP-CS-Fixer
• PHP PEAR coding standards
• PHP-FIG's PSR
• WordPress Coding Standards

Thanks @jrchamp and Brad.

On this screen : https://equalify.lndo.site/index.php?view=scans
(I'm using Lando to host it locally)

Warning: Undefined variable $records in /app/models/db.php on line 397 Fatal error: Uncaught Exception: 
Cannot insert scan with status "running" and records "" in /app/models/db.php:397 Stack trace: #0 
/app/actions/scan_all_pages.php(28): DataAccess::add_scan('running', 'a:2504:{i:0;a:1...') #1 {main} thrown 
in /app/models/db.php on line 397

This suggests that it can't connect to SQL?

But I was able to add a site, that generates a list of pages to scan.

Unsure how to fix.
Thanks

The guiding belief behind Equalify is that people want an easy-to-use WCAG scan that scans any site.

MVP 3 tests that principle with a fully functional version of the app. Users can add their sites, and run them against the WAVE WCAG scan.

I'll look for missing features and general bugs. I'll also look for interest.

Every user will be onboarded during a 30-minute call. Users will share their screens as I help them set up the service and add a few sites. I'll schedule a follow-up call after one to two weeks of using it. Users are also invited to submit any bugs or issues to the repo's issues tab.

By the end of this test, I hope to know what features users are interested in.

The MVP test is scheduled to commence on September 6, 2022.

Let's see what happens!

We should add a new archived column with bool data to the alerts table.

Kate was trying to add https://postersmysell.psych.hms.harvard.edu/

The site thows up this error:

Fatal error: Uncaught Exception: The URL "https://postersmysell.psych.hms.harvard.edu/" is not valid output in /var/www/html/models/adders.php:80 Stack trace: #0 /var/www/html/actions/add_site.php(42): wordpress_site_adder() #1 {main} thrown in /var/www/html/models/adders.php on line 80

She is currently running on CampusPress.

Even though "alerts" shows a link to a report, it might be better UX to link to the alert page while browsing pages?

New scans should mark alerts "completed".

Instead of relying on third-party services, an integrated scan allows us to build a custom report.

Here's a great library of JS WCAG concerns: https://github.com/SSAgov/ANDI/blob/master/andi/andi.js

Lots of people use management plugins, like the Accessibility Checker. Instead of requiring that users integrate with a cloud service, how can we integrate with other plugins?

Kate tried to scan https://construction.harvard.edu/

The scan failed on this URL https://construction.harvard.edu/sample-page/

The Bounty

Equalify includes $existing_alerts and $queued_alerts.

We want to compare those multi-dimensional arrays, then move any duplicates to a $duplicate_alerts variable.

For solving this bounty, a user will receive $111.

Requirements

Your code must:

1. Compare the 'type', 'source', 'url', and 'message' of each array in$existing_alerts and $queued_alerts.
2. When the values of those properties match, the entire array is moved to $duplicate_alerts.
3. Avoid closures and arrow functions.

Why avoid closures?

Equalify is made for everyone. That means our code should be accessible. Closures rely on abstractions that we want to avoid in our app. Any solution should be understood by someone who doesn't understand PHP closures.

Example and Desired Output

To start, you should use these two variables:

$existing_alerts = array(
    array(
        'id' => '1',
        'time' => '2022-07-19 13:54:30',
        'status' => 'active',
        'type' => 'notice',
        'source' => 'little_forest',
        'url' => 'https://decubing.com',
        'message' => '[code]<title>...</title>[/code]Check that!',
        'meta' => 'a:2:{s:9:"guideline";s:43:"WCAGtle";}'
    ),
    array(
        'id' => '2',
        'time' => '2022-07-19 13:54:30',
        'status' => 'active',
        'type' => 'notice',
        'source' => 'little_forest',
        'url' => 'https://equalify.app',
        'message' => '[code]<title>...</title>[/code]Check that!',
        'meta' => 'a:2:{s:9:"guiitle";}'
    )
);

$new_alerts = array(
    array(
        'status' => 'active',
        'type' => 'notice',
        'source' => 'little_forest',
        'url' => 'https://wpcampus.org',
        'message' => '[code]<title>...</title>[/code]Check that!',
        'meta' => 'a:2:{s:9:"guideline";s:43:"WCAGtle";}'
    ),
    array(
        'status' => 'active',
        'type' => 'notice',
        'source' => 'little_forest',
        'url' => 'https://equalify.app',
        'message' => '[code]<title>...</title>[/code]Check that!',
        'meta' => 'a:2:{s:9:"guiitle";}'
    )
);

Your function should compare those two arrays and output the following:

$existing_alerts = array(
    array(
        'id' => '1',
        'time' => '2022-07-19 13:54:30',
        'status' => 'active',
        'type' => 'notice',
        'source' => 'little_forest',
        'url' => 'https://decubing.com',
        'message' => '[code]<title>...</title>[/code]Check that!',
        'meta' => 'a:2:{s:9:"guideline";s:43:"WCAGtle";}'
    )
);

$new_alerts = array(
    array(
        'status' => 'active',
        'type' => 'notice',
        'source' => 'little_forest',
        'url' => 'https://wpcampus.org',
        'message' => '[code]<title>...</title>[/code]Check that!',
        'meta' => 'a:2:{s:9:"guideline";s:43:"WCAGtle";}'
    )
);

$duplicate_alerts = array(
    array(
        'status' => 'active',
        'type' => 'notice',
        'source' => 'little_forest',
        'url' => 'https://equalify.app',
        'message' => '[code]<title>...</title>[/code]Check that!',
        'meta' => 'a:2:{s:9:"guiitle";}'
    )
);

NOTE: Your solution should be able to handle different values and arrays that contain thousands of nested arrays.

Submitting a Solution

Submit a pull request from the bounty-2 branch. Add your solution as a new PHP file.

The first solution that fulfills the requirements, gets $111 via Venmo/PayPal.

Cash can also be donated to a cause.

Good luck!

We need to filter by URL

Wouldn't it be cool if we could ignore certain types of alerts?

I imagine we would have an "Ignore Rules" button on the ignored alerts page.

That would lead to a list of various rules.

You can add a new rule on that page or from a dropdown nested with the "Ignore Alert" button.

Rules would be similar to labels. You could ignore a status, alert type, or meta value.

Whenever a scan runs, alerts that meet the criteria would be automatically marked "ignored".

Equalize Digital makes an accessibility checker that largely runs on local WordPress installs.

Perhaps we should integrate with their checker?

I'm only interested in working with ethical companies. There's too much money in tech to just do things for money. What is the altruistic purpose of this app?

As #38 demonstrates, we may need to create a docker container so that users can quickly spin up and test their own distribution.

Perhaps we can add a new meta type called "Tags" when any alert include meta formatted like a tag, that tag will be displayed and also be filterable? IE-

Array(
   'tags' => array(
      'Tag 1', 'Tag 2', 'Tag 3'
   )
)

Perhaps users need an accessible data visualizations of alerts and scans over time?

As Doug reminded me, manual scans don't reveal all the accessibility issues.

Most sites need to be manually reviewed in order to meet all WCAG policies.

Using just a second-level and top-level domain (e.g. graceblake.com) throws an exception. PHP's FILTER_VALIDATE_URL filter doesn't consider it a URL.

This isn't a great user experience, but may not be a bug if you want to force the protocol to be specified.

If website doesn't exist, this error comes up:
Fatal error: Uncaught Exception: The URL "journeys.dartmouth.edu/billtest02" is not valid output in /var/www/html/models/adders.php:80 Stack trace: #0 /var/www/html/actions/add_site.php(42): wordpress_site_adder() #1 {main} thrown in /var/www/html/models/adders.php on line 80

I saw a recent OCR complaint that was filed because a school failed to use alt tags.

Computer vision has been solving this problem with tools like Automatic Alternative Text.

Automated tools aren't perfect, but they can work toward better A11Y.

I would love to see an integration that:

1. Scans for missing alt text
2. Offers suggestions for the alt text
3. Allows users to accept suggestions
4. Changes the alt text

We could learn from changes users make to the suggestions and improve the robot.

The hope is that users would accept all suggestions eventually.

That would allow Equalify to automatically replace alt text, and would lead to a more accessible internet.

What is the goal of this sprint?

Build an MVP that alerts users of WCAG errors using 2 integrations.

What is the deadline?

April 25: Drupalcon

Why is the sprint important?

Get da thing built!

Expected Logic:

When you archive a site, all alerts related to that site will be archived.
When you archive an integration, all alerts related to that site will be archived.

When you activate a site, all alerts related to that site and any active integration will be activated.
When you activate an integration, all alerts related to that integration and any active sites will be activated.

Current behavior:

Activating a site activates all alerts related to the site, even if the integration related to those alerts is deactivated.
Activating an integration activates all alerts related to the integration, even if the site related to those alerts is deactivated.

I imagine "Alerts" becoming "Policies" if we provide deeper integration with WordPress or Drupal via a module/pugin.

In theory, every WordPress hook can be used to trigger another hook or an alert. Users can also use endpoints from other services, like an accessibility scanner or the WP Plugin Repository, to trigger an infinite variety of automated enforcement events or alerts.

A Few Examples

• WordPress site publishing is disabled and the system admin is alerted if there are over 20 WCAG errors.
• System Admin is Alerted if a plugin is out of date.
• WordPress users are prevented from editing the header of any site.

To do enable these features, we would have to develop a plugin that spoke with the cloud app.

For the Scan page, what if you don't want to scan all pages of all sites? What if you have hundreds of sites for example? Should there be an option to scan only certain sites? Maybe only ones that haven't been scanned in a while (or since a date that you enter)? Otherwise it could take a long time, right?

Checkout the TODO in actions/update_meta.php ..

The current logic for updating the wave key is hardcoded there.

In the very near future, we should update the logic so that these meta updates can be set in the integration's functions.php file.

Many sites I've added have thousands of alerts per page.

Maybe we need to show which alerts are read and unread, like a gmail for webops alerts?

Wouldn't it be cool to be emailed a customizable digest of alerts and when scans complete?

I added some sites and ran some scans, but the badges are always showing up as 'Unscanned'.

Either the scan completion logic doesn't properly update the DB, or the frontend isn't pulling the right data.

I didn't plan on making every $db call a function, but it happened.

Now I have to require models/db.php and $db every time I want to query the db.

I know that creates lots of redundancy.

Curious if there is a simpler solution?

The word "Forest" is consistently misspelled as "Forrest". I was about to make a pull request, but didn't proceed because the change would require database updates.

Perhaps users will want to autoscan sites on a set frequency ie- daily, monthly, weekly, annually..

This can just be a setting in the account page..

Currently, we send a URL to web services in a foreach loop.

That means we have to wait to receive the output from the web service before we can add alerts.

To speed things up, we should send multiple URLs to the web service at once.

To do that, we would need to add $integration_alerts($page) function in an async loop.

The winner of this bounty must implement a concurrent process that sends multiple URLs to integrations without waiting for previous URLs to be processed.

Feel free to add third-party integrations like AMP, which should be added via Composer.

You should not use added PHP extensions.

Please pull from the mvp1.2-controller_scanning branch.

Winning solutions will be judged the solution's "readability" and performance.

Winner gets $333 to a charity or PayPal/Venmo account of their choice.

Good luck!

The average site has over 1000 accessibility errors. We would have to create some kind of a summary of errors. This is perhaps used in a "notifications" tab. That tab can select from weekly, daily, or monthly notifications.

Perhaps notifications are just handled in an integration? I could imagine users wanting different types of notification integrations. For instance, they could use sendgrid. Handling notifications and integrations would also free up the user interface. The only thing is that it could be less intuitive for users to have to click on an integration to update their notifications them to just click any notifications tab.

If every user would want to notifications, why would it be an integration?

Alerts are a core function of Equalify.

Users use our app to get alerts from many web services in one place.

Running our scans over hundreds of pages equates to thousands of alerts.

We need to filter alerts.

Nope! All you need is a publicly-facing URL.

That said, you can add WebOps enforcement by adding the Equalify plugin to any property.