This module validates whether a Drupal developer understands where presentation ends and logic begins. Acquia is not testing visual design skills. It is testing architectural discipline.
Most real-world Drupal issues related to accessibility, maintainability, and performance are caused by misuse of HTML and CSS rather than PHP mistakes.
1. HTML in Drupal is generated, not handwritten
In Drupal, developers rarely write raw HTML directly. HTML is produced through a layered rendering process.
Where HTML comes from
- Controllers return render arrays, not HTML
- The Render API processes render arrays
- The theme layer converts render arrays into HTML using Twig
- The browser renders the final DOM
Key rule: Writing HTML inside PHP code is almost always incorrect.
If an exam question suggests generating HTML in a controller or service, that option is wrong.
2. Semantic HTML is a core Drupal expectation
Drupal core assumes semantic HTML usage and outputs semantic markup by default.
Example Twig template output
<article{{ attributes }}>
<h2>{{ label }}</h2>
{{ content }}
</article>
This structure is intentional and should not be replaced with generic div elements.
Drupal core assumes semantic HTML usage and outputs semantic markup by default.
Common Drupal mappings
- Nodes are rendered as article elements
- Menus are rendered inside nav elements
- Blocks are rendered as section or aside elements
- Main page content lives inside a single main element
These elements are meaningful to screen readers, search engines, and accessibility tools.
Using div elements everywhere breaks this contract and is discouraged.
3. Real-world scenario – government and enterprise sites
Scenario: A government site lists multiple safety bulletins on a page.
Correct Drupal solution:
- Use a View to list content
- Each item is rendered as an article element
Incorrect solution:
- Wrap all content inside generic div containers
Why this matters:
- Screen readers cannot distinguish individual content items
- Accessibility compliance fails
- Search engine structure is weakened
Acquia exams strongly favor semantic correctness in these cases.
4. Accessibility is mandatory, not optional
Accessibility is built into Drupal core assumptions and is frequently tested.
Example form markup
<div class="form-item">
<label for="edit-email">Email address</label>
<input type="email" id="edit-email" name="email" />
</div>
Using proper labels ensures keyboard and screen reader compatibility.
Accessibility is built into Drupal core assumptions and is frequently tested.
HTML accessibility responsibilities
- Every form input must have an associated label
- Images must have appropriate alt text
- Headings must follow logical order
- Buttons are used for actions
- Links are used for navigation
Example
Incorrect:
- Using anchor tags to submit forms
Correct:
- Using button elements for actions
Buttons support keyboard navigation, screen readers, and browser defaults.
5. HTML vs CSS responsibilities
Understanding this separation is critical for both the exam and real projects.
HTML is responsible for:
- Structure
- Meaning
- Content hierarchy
CSS is responsible for:
- Layout
- Spacing
- Colors
- Typography
Spacing or layout changes should never be solved by modifying Twig or adding HTML elements.
6. CSS usage in Drupal
CSS should be managed using libraries.
Example libraries.yml definition
mytheme-global:
css:
theme:
css/style.css: {}
Attaching a library in Twig
{{ attach_library('mytheme/mytheme-global') }}
CSS should never be written inline or embedded directly in Twig templates.
CSS should be managed using libraries.
Correct Drupal approach
- Define CSS in libraries.yml
- Attach libraries globally or contextually
- Allow themes to override module styling
Inline styles and editing module CSS files are considered bad practice.
7. Overridable design philosophy
Drupal is designed so that:
- Modules provide functionality
- Themes control presentation
- Subthemes override base themes
Editing module CSS directly causes update failures and prevents clean overrides.
Exam answers always prefer theme-level overrides.
8. Drupal HTML output and contextual classes
Drupal automatically adds contextual classes such as:
- node--type-article
- node--view-mode-teaser
These classes should be used for styling instead of adding custom IDs or logic.
Example use case:
Different styling for teaser vs full view mode should be handled with CSS using these classes.
9. CSS specificity in Drupal
Preferred approach:
- Use class selectors
- Avoid ID selectors
- Avoid important declarations
Drupal provides sufficient contextual classes to avoid fragile selectors.
10. Separation of concerns
This principle appears throughout the Acquia exam.
- PHP handles logic and data preparation
- Twig handles markup structure
- CSS handles presentation
- JavaScript handles behavior
Example preprocess function
function mytheme_preprocess_node(array &$variables) {
$variables['is_featured'] = $variables['node']->hasField('field_featured') && !$variables['node']->get('field_featured')->isEmpty();
}
Twig usage
{% if is_featured %}
<span class="badge">Featured</span>
{% endif %}
Logic should not live directly in Twig templates.
This principle appears throughout the Acquia exam.
- PHP handles logic and data preparation
- Twig handles markup structure
- CSS handles presentation
- JavaScript handles behavior
Logic should not live in Twig templates, and layout should not live in PHP.
11. Production failure patterns
Common real-world issues caused by ignoring these principles:
- Inline CSS leads to unmaintainable code
- Non-semantic HTML causes accessibility failures
- Twig logic becomes unreadable
- Module CSS edits break updates
Acquia exams test whether you can avoid these mistakes.
Key exam takeaways
- Drupal generates HTML through the Render API and theme layer
- CSS should be attached using libraries
- Semantic HTML improves accessibility and SEO
- Themes control presentation while modules control logic
Practice check
- Where does spacing belong: CSS
- Where does structure belong: Twig
- Where does logic belong: PHP and preprocess functions
- Where does accessibility apply: everywhere