Fixing technical errors on the OpenCart website

Website: https://gerts.com.ua/ 

Problems: 

Headings H1-H6

What needs to be done:

1. Leave only one <h1> on the page

Editable through the admin panel

2. Use <h2> only for main sections:

• Product catalog
  
  

• Best sellers
  
  

• Promotional offers
  
  

• What people say about the products
  
  

• About us
  
  

• Questions and answers
  
  

• Latest articles
  
  

3. Inside sections “Product catalog” — use <h3> only for subcategories:

Example:
<h2>Product Catalog</h2>

  <h3>Targets</h3>

  <h3>Stickers</h3>

4. The names of the products themselves should NOT be headings

Instead of <h3>Product Name</h3> use:

<strong class="product-title">

  <a href="/product-url">Product Name</a>

</strong>

or

<a href="/product-url" class="product-title">Product Name</a>

Advantages (1 million+, 20+, 3 years, etc.)

• Can be left as <p> or <div>, styled visually as a heading if needed, but do not use <h2> or <h3> unless they carry structural value.
  
  

6. Check the final structure

• Ensure that hierarchy is not broken (<h3> does not come before <h2>, no duplicate <h2> in a row without context)
  
  

• Validate HTML for correctness
  
  

WebP Image Support Module:

It is necessary for the module to automatically convert images to WebP format

• Install and configure the Gum Image Optimizer module

Additional actions needed:

1. Verify that WebP images are actually delivered to browsers
   
   

• Ensure that the server correctly serves WebP versions instead of original JPEG/PNG if supported by the browser
  
  

• Check .htaccess

2. Enable and test Lazy Load
   If a plugin is used (e.g., WP Rocket, native lazy load, Gum), ensure that:
   
   

• Lazy Load is enabled
  
  

• All <img> tags have the loading="lazy" attribute
  
  

3. Check sizes and responsiveness
   
   

• All images should have specified width and height
  
  

• Fix srcset and sizes so that the browser loads the needed size
  
  

4. Check caching
   
   

• Ensure images are cached on the browser side (expires, cache-control)
  
  

5. Check Lighthouse
   
   

• Run the page through Google Lighthouse (in Chrome DevTools)
  
  

• Ensure there are no warnings regarding images (size, format, lazy load, etc.)
  
  

Result:

• Images load quickly without breaking the layout
  
  

• No duplicates or unnecessary weight
  
  

• WebP works
  
  

• Lighthouse metrics for images without errors
  
  

Ensure all buttons on the site:

• Are properly marked (<button> or <a>)
  
  

• Work with keyboard
  
  

• Are accessible for screen readers
  
  

• Meet WCAG 2.1 and Lighthouse recommendations

1. Semantics

• Use only native tags:
  
  

• <button> — for actions (submit, close, open, etc.)
  
  

• <a href="..."> — for navigation
  
  

• Prohibit using <div> or <span> as buttons (unless role="button" + tabindex + handling Enter/Space — but better to replace with <button>)
  
  

2. Button type

• For buttons in forms:
  
  

• Explicitly specify type="submit" or type="button"
  
  (by default <button> = submit, which can cause unwanted behavior)
   

3. Keyboard accessibility

• All buttons should be accessible via Tab
  
  

Buttons should activate with keys:

• Enter

• Space

    4. aria-attributes and descriptions

• All buttons should have:
  
  

• Either visible text (<button>Download</button>)
  
  

• Or aria-label="Download" — if the button contains only an icon
  
  

Ensure accessibility of all form elements

Goal: Improve accessibility of forms for users with special needs and meet WCAG standards.

Check and correct the behavior of the country selection field (phone input)

What to do:

• The element .iti__selected-flag should not be focusable on its own unless it manages input.
  
  

• Remove tabindex="0" and role="combobox" from elements that are not active controls.
  
  

• Ensure that keyboard navigation (Tab) moves strictly between interactive elements (input, select, button).

Check the presence and correct markup of the submit button

What to do:

• Ensure that the form contains a button type="submit" or input type="submit".
  
  

• If missing — add:

Improve ARIA attributes

What to do:

• Leave aria-label or aria-labelledby if no label exists, but prefer using <label> as the main means.
  
  

• If there is field validation, add aria-describedby="message-id" and aria-invalid="true" on error.

Test focus and navigation

Test manually:

• Tab key should move sequentially through:
  
  

  • the “Name” field;
    
    

  • the “Email” field;
    
    

  • the phone field;
    
    

  • the submit button.
    
    

• Enter/Space keys should activate submission and clickable elements.
  
  

• There should be no “jumps” or focus on decorative blocks.
  
  

Reduce delays when connecting to third-party services

• Identify all third-party scripts being loaded (e.g., analytics, fonts, widgets).
  
  

• Implement lazy loading for non-essential scripts.
  
  

• Use async or defer when connecting third-party JS resources, if possible.
  
  

• Optimize the order of third-party services so they do not block critical page rendering.

Ensure sufficient contrast between background and text color

• Use contrast checking tools (e.g., WebAIM Contrast Checker).

• Verify that contrast between text and background meets WCAG minimum requirements:

• AA level: at least 4.5:1 for normal text, 3:1 for large text.

• AAA level (recommended): 7:1 for normal text.

Ensure correct semantic structure of <li>

Goal: Maintain proper HTML structure and improve content perception by assistive technologies.

What needs to be done:

• All <li> tags should only be used inside lists <ul>, <ol>, or <menu>.
  
  

• Avoid cases of:
  
  

• <li> outside a parent list;
  
  

• <div><li>...</li></div> without nesting in <ul> or <ol>.
  
  

• Replace incorrect <li> with <div>, <p>, or other semantically appropriate tags if needed.
  
  

• Ensure list structure is logical and properly nested (nested lists are correctly displayed and styled).

Fix incorrect ARIA role assignments

Goal: Ensure proper operation with assistive technologies (screen readers, VoiceOver, etc.).

What needs to be done:

• Check all role attributes for correctness and necessity.
  
  

Avoid cases of:

• Assigning role="button" to <button> — this is redundant;
  
  

• role="link" on <a> with href — also redundant;
  
  

• Using deprecated roles or invalid values.
  
  

• Use only valid values from the official  WAI-ARIA specification.
  
  

• Check that all ARIA roles are logical in context, for example:
  
  

• role="navigation" — for menu blocks;
  
  

• role="dialog" — for modal windows;
  
  

• role="alert" — for error and warning notifications.

Properly fill in the href attribute for links

Goal: Ensure correct navigation and link behavior on the site.

What needs to be done:

• All <a> tags must have a filled href attribute. Avoid:
  
  

• href="";
  
  

• href="#" — only if used with JavaScript, and then with preventDefault() (in popup forms).
  
  

• For external resources — absolute links with https:// protocol, with rel="nofollow noopener noreferrer" closed tags
  
  

• If the link opens in a new tab (target="_blank"), be sure to add:
  
  

  • rel="noopener noreferrer" — for security (to prevent window.opener vulnerability).
    
    

Additional:

• After implementing all points, conduct an audit:
  
  

  • Lighthouse (in Chrome DevTools, "Audit" or "Check" tab);
    
    

  • axe DevTools — for in-depth accessibility testing.
    
    

• It is recommended to record test results with screenshots before and after changes.