I originally used 'display_level' when reporting what later became known as the severity of a particular problem.
Having both 'display' and 'severity' refer to the same thing is confusing.
Be consistent and use 'severity'.

I need to do some more extensive research in migrating this.
I am removing this because the drupal 8 api views implementation may be best served by creating an Entity type for quail api problems.
This may be an extensive change, so instead I am going to focus on getting an alpha release sooner.

This requires putting a catch for both Exception and Error.

These extra rows turn out to be additional information provided for particular results.
I have never noticed this before, so it is likely also a bug in the Drupal 7 version of this module.

The line number and code snippet are not being displayed.
The code was never finished, I just never noticed.
This also adds additional span classes wrapping the code for additional theme customization.

The theme template is already piping the data to a sanitization function, which is apparently what t() does.

This moves the code store in quail_api.module into different classes.
This is not a full drupal 8 style usage, which should likely utilize the Plugins API.

I am not implementing this via Plugins API (or something similar) particularly because I want to focus on getting a Drupal 8 production release sooner than later.
I can come back later and implement a 2.x version that more thoroughly utilizes the Drupal 8 APIs to their fullest extent.
These plans should be considered tentative.

Just use insert() instead.
I believe that the current implementation deletes existing rows before adding, so a merge would be pointless anyway.
- If this is wrong, then a new bug will appear.
- Long term, I would like to avoid deleting existing rows so that I do not eat up the serial id count.

Update: code cleanups and minor modifications resulting from relate work in node_accessibility module

I realized that the reason the twig files had to be in include was because of the old 'path' option in hook_theme().
There is no reason to specify that, so get rid of it.
Now the templates are where they are expected to me according to the drupal 8 standards.

This adds an option in the quail settings page for adjusting the default title tag used.
This is not intended to cover all the possibilities.
It is simply just a good enough for now approach, providing only a very basic collection of options.

Heading 3 is chosen for traditional accessibility compatibility.
Page title should be H1.
Page menus and sections or blocks should be H2.
All entries below this would be H3, which is where the title block comes into play.

Yes, headings are horribly limited, in part due to how HTML5 limits their number, but also in part due to how the accessibility requirements define their usage.
This adds the option to give you the choice to follow that convention or not.

This also adds the P tag and enables the H1 tag.

Drupal 8 replaced using fieldsets for open/close boxes with the HTML5 <details>.
Note: Internet Explorer may not support <details>.

Migrate: Utilize drupal 8 filter format default on presentation and add administration settings page

I manually added a link menu, called 'accessibility.admin_index'.
I think accessibility is a common think and may, in the future, suggest the inclusion of an 'accessibility.admin_index' admin config path in drupal 8 core.

Update: add drupal 8 version of drupal_alter(), restoring previously removed hooks during migrate changes

I removed the drupal_alter() instances in a previous migrate commit.
I discovered that there is a \Drupal::moduleHandler()->alter() call available that is essentially drupal_alter().
This will allow me to preserve the previous behavior for allowing other modules to alter quail api properties.

This is added in theory and is untested.

I also noticed that the previous design was calling the drupal_alter() even when cache is available.
This time, if the cache exists, then the appropriate hooks were already called and do not need to be called again.

I have begun my work on migrating node_accessibility.
This is a collection of changes made while migrating node_accessibility.

The drupal 7 code used the template preprocess hooks to initially variables.
With drupal 8, this becomes a problem because variables are pre-processed and initialized by twig.
Thus, the drupal 7 code would overwrite the variables provided by drupal 8.

The drupal 8 document claims that the twig templates should be in the templates directory and have '-' in place of '_'.
However, in practice, I received errors where twig was looking for the variables in the includes directory and with '_' instead of '-'.

Much of the code still present is needs to be updated, replaced, or removed.

Drupal 8 examples show that the Unicode class is to be used for calling strtolower, but I had class undefined errors and was forced to call strtolower() direc
This will be a problem with multibyte, but is good enough for a temporary setup until I finish implementing and testing the node_accessibility module.

The database information will probably be removed.
I intend to utilize drupals entity crud for attaching the validation results on a per node basis.
This might become a problem, performance-wise, when generating statistics, but I won't know until I try.
This approach will (ideally) allow for better integration and less work on my end.
The downside is that there will be more work when it comes to providing a database migration functionality from d7 to d8.

I am going to remove code that I have not yet migrated and then add it back once I can learn, test, and confirm it is working.
This will help me avoid stale code issues resulting from the migrate.

The drupal 8 method now requires using '#attached'.

More work may be necessary to get this CSS files 'attached'.

see: https://www.drupal.org/node/2169605

This module does not directly implement any permissions.

This module only used hook_permissions() as a way to allow dependency modules to have all permissions grouped together.

Dependency modules will now need to define their own $module.permissions.yml file instead of calling quail_api_permission_alter().

Update: remove table summary tests from wcag 2.0 because the summary attribute it is deprecated, confusing, and problematic