We have a custom theme, vagovclaro, on which we're dependent for maintaining accessibility standards, user experience requirements, and so forth. As noted by @edmund-dunn we are also tightly coupled to the parent theme, claro, which is maintained within Drupal Core. That coupling can impair our flexibility in dealing with issues in one or the other.
Tasks
[ ] We should audit this theme and determine:
[ ] Risks posed by the current structure
[ ] Misallocations, e.g. code in the custom theme that should reside in custom modules or config, and code in config or custom modules that should reside within the custom theme
[ ] How best we can address our current shortfall in testing coverage of functional requirements within the purview of this (or any other) custom theme.
[ ] A strategy for addressing deficits
Acceptance Criteria
[ ] The CMS team has met as a whole to discuss the topic in general (short meeting, like 15 minutes hopefully).
[ ] Main objective: Get UX and A11y input on what we should cover, what we should demand, etc.
[ ] Mini-Deliverable: Unvarnished opinions on what we need to do to reduce their stress re: design system compatibility, accessibility, etc within Drupal itself.
[ ] Findings documented in this thread.
[ ] The DevOps and Drupal engineers have met or asynchronously discussed how to solve these problems.
[ ] Findings documented in this thread.
[ ] Followup issue(s) opened to address individual points.
Description
We have a custom theme,
vagovclaro
, on which we're dependent for maintaining accessibility standards, user experience requirements, and so forth. As noted by @edmund-dunn we are also tightly coupled to the parent theme,claro
, which is maintained within Drupal Core. That coupling can impair our flexibility in dealing with issues in one or the other.Tasks
Acceptance Criteria
Previous Team Points
8