Posted by jlincct on February 3, 2016 at 4:10pm
Should we create our own custom module and sub-theme and implement following hooks to do the accessibility remediation?
Thanks.
Should we create our own custom module and sub-theme and implement following hooks to do the accessibility remediation?
Thanks.
Comments
Yes and more
Hi jlincct,
Yes, many of the _alter and _preprocess hooks you mentioned will be useful. In addition, you should use _theme() hooks and theme files to override markup. Theme overrides can change the markup that comes from core, from the existing theme, and especially from Views.
When overriding Views theming, there is a naming convention that allows you to put files into your theme (or sub-theme) that will override different views and views displays. You can override any part of a specific view by naming your file appropriately: EG, views-view-fields--mylisting--block.tpl.php will override the fields in the block display of the view called "mylisting".
I would suggest putting all of the theme overriding into a sub-theme. If the (parent) theme is a third-party of contrib theme downloaded from drupal.org, you don't want to "hack" it. Instead you want to cleanly use a sub-theme to override what you need. That way you can still apply updates from drupal.org when new versions come out.
It's the same thing for Drupal core or for other contrib modules. You might need to use _alter or _preprocess hooks to modify things, but put those changes into your own module so that you aren't hacking core. You can create a new module, like myclient_accessibility_fixes.module, if you need a good place to put all of this.
I hope all this is helpful and addresses your question. One last piece of advice: if you find something inaccessible about Drupal core or about contrib modules or themes, file an issue on Drupal.org. Here is a decent guide about how to file an issue: https://www.drupal.org/issue-queue/how-to. And tagging it with the tag "Accessibility" will help too. Best Wishes to you!
www.pixotech.com