Plugable Quail Architecture

[WilcoFiers]

This proposal is based on a discussion with KING, Jesse, AccessibilityNL and CKSource. A number of issues have come up which can all be boiled down to the same issue, a limited flexibility in the architecture of Quail.

In brief, these issues are:

• Put the KING assessments in their own package
• Make it easier for third party contributors by allowing customization assessments or adding their own
• Allow Quail to have a stable/finished 'core' that requires little maintenance VS Allow Quail assessments to be improved iteratively over time.
• Have Quail function as a wrapper for third party test libraries such as W3C validator and Google's Accessibility Developer Tools.
• Reduce the size of Quail's build

---

A potential approach for all of these issues could be to break Quail up into different components. The core would only be focused on loading assessments, running them, and reporting their findings. All the assessments that are currently in Quail will be moved to separate Quail-* packages.

Quail core would need a standardized way of installing and running these external packages. This method should be transparent, flexible and easy to pick up. This would make it possible for developers to make their own assessment libraries for Quail.

The following benefits would be gained by using this approach:

• There is a clearer separation of responsibilities within the architecture of Quail. This also allows for easier delegation of responsibilities about certain 'parts' of Quail to those people most concerned with them
• Large dependencies used for assessments don't have to be included by default
• The main Quail repository will require less work as it reaches a stable version, while still allowing for a vibrant and active development cycle on the assessments themselves
• It makes Quail potentially useful for general quality testing, not just a11y testing.
• Allows Quail to work with third party assessments without them having to branch the core project
• Makes it easier for people new to Quail to develop assessments, as there is a standardized (and documented!) way to do this work.

There are a number of disadvantages to this approach too:

• Additional resources are required to develop and maintain this architecture
• An extra layer of complexity is added to Quail with this introduction of external assessment libraries
• Managing updates to Quail core becomes more complicated and risky because changes have the potential of causing errors in third party assessments.
• It makes sense to build this into Quail 3, but it would also introduce a delay in it's release.

[jessebeach]

The goal is commendable.

This topic is better represented as a Milestone that groups actionable tasks. We could never close this task because it has too many unknowns.

[mlewand]

That's a good idea. It would make sense to split it into a separte npm packages.

• quail-core
• quail-assessments-a11y
• quail-assessments-king
• quail-assessments-foo

A question that bothers me is that utils functions would also need its separate package.

• quail-utils-a11y Methods like isDataTable, isUnreadable, getTextContents (that is aware of a11y)
• quail-utils-dom Methods like getTableMap, getTextContents (that works only on text nodes) and any DOM traversing methods.
• quail-utils-css Methods like defineUniqueSelector (though it might be merged with quail-utils-dom)

The point here is that they should not be bundled within e.g. quail-assessments-a11y module, as any other might want to reuse these utils.

Eventually we might also need a way to add Quail components:

• quail-components-selector
• quail-components-event

Then we'll during building process we'll use browserify to merge modules into file executable in target browsers.

We'd be very happy to see it.

[WilcoFiers]

Excellent question. I'd go further and split up assessments-a11y as well. I expect there are logical ways to group some of these together, like WCAG conformance assessments, precontition assessments, and probably a few more. I haven't spend much time on this idea yet. I think some of these functions should stay and core while others can move into their own packages. Quail is and will stay an accessibility testing tool, so having features in core that support that bases makes sense. But when we start loading external dependencies, these are probably best put only in the packages that rely on them.

[jessebeach]

I've just refactored Quail into a modular build structure. I can now start separating into individual projects.

[jessebeach]

We've got the pluggable architecture now in master.

https://github.com/quailjs/quail/pull/386

We've got a separate ticket to pull out the KING tests.