Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
121 changes: 121 additions & 0 deletions .github/acc-test-page-generation.instructions.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,121 @@
## API Test Page Generation Guidelines

I need you to create a comprehensive API test page for the provided components.

Each component has the following relevant files in its directory main/fiori:
- [COMPONENT_NAME].ts - Component logic and properties
- [COMPONENT_NAME]Template.tsx - Component structure and markup; Traverse this file to understand how the component is built, and if available find the sub-templates and index them as well, e.g. ColorPaletterteTemplate.tsx and ColorPaletteItemTemplate.tsx;
- [COMPONENT_NAME].html - Component html structure reference
- [COMPONENT_NAME].css - Component styles
- APIs_Template.html - For styling and structure reference

Task Requirements:

1. API Analysis & Documentation
- Analyze all API's of the component, and generate separate examples for each one of them
- Document ARIA attributes, and roles only for the accessibility related API's
- Identify keyboard navigation patterns and focus management
- Analyze component-specific interactions
- Do NOT use any deprecated API's
- For specific features or functionalities such as F6 Navigation, localization, theming, etc., ensure to include relevant imports
- Ensure all necessary assets are imported for proper component rendering and functionality

2. Test Page Structure
- Follow strictly the styling and structure of APIs_Template.html, do not change any styling and do not add any from your side to the structure, replace whats instructed there
- Create clear section headers with consistent card-based formatting
- Use [COMPONENT_NAME].html only as a reference to understand how the component is used, do not copy or replicate code from it
- Create fresh, original examples based on the component's APIs
- Do not use <kbd>, <code>, or any other semantic or inline tags for keyboard keys, code, or emphasis

3. Test Implementation
- Generate working component examples for each API
- Include interactive demonstrations of ARIA attributes and roles
- Add keyboard navigation testing scenarios
- Provide screen reader compatibility examples
- Include test instructions only for interactive demonstrations that require user action to see the API working
- Create the file in acc-tests/packages/main/test/pages directory, NOT in the submodule
- File name: [COMPONENT_NAME]_APIs.html

## APIs_Template.html File Structure

```html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>UI5 [COMPONENT_NAME] API Samples</title>
<meta name="viewport" content="width=device-width, initial-scale=1.0">

<!-- DO NOT change, use as it is-->
<script type="importmap">
{
"imports": {"@ui5/webcomponents/":"https://cdn.jsdelivr.net/npm/@ui5/webcomponents@2.15.0-rc.0/","@ui5/webcomponents-ai/":"https://cdn.jsdelivr.net/npm/@ui5/webcomponents-ai@2.15.0-rc.0/","@ui5/webcomponents-fiori/":"https://cdn.jsdelivr.net/npm/@ui5/webcomponents-fiori@2.15.0-rc.0/","@ui5/webcomponents-compat/":"https://cdn.jsdelivr.net/npm/@ui5/webcomponents-compat@2.15.0-rc.0/","@ui5/webcomponents-base/jsx-runtime":"https://cdn.jsdelivr.net/npm/@ui5/webcomponents-base@2.15.0-rc.0/dist/jsx-runtime.js","@ui5/webcomponents-base/":"https://cdn.jsdelivr.net/npm/@ui5/webcomponents-base@2.15.0-rc.0/","@ui5/webcomponents-icons/":"https://cdn.jsdelivr.net/npm/@ui5/webcomponents-icons@2.15.0-rc.0/","@ui5/webcomponents-localization/":"https://cdn.jsdelivr.net/npm/@ui5/webcomponents-localization@2.15.0-rc.0/","@ui5/webcomponents-theming/":"https://cdn.jsdelivr.net/npm/@ui5/webcomponents-theming@2.15.0-rc.0/","lit-html":"https://cdn.jsdelivr.net/npm/lit-html@2","lit-html/":"https://cdn.jsdelivr.net/npm/lit-html@2/","@zxing/library/":"https://cdn.jsdelivr.net/npm/@zxing/library@0/"}
}
</script>

<script type="module">
// [AI_REPLACE_START: Component Imports]
// [AI_REPLACE_END]
</script>

<!-- Bootstrap CSS -->
<link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.2/dist/css/bootstrap.min.css" rel="stylesheet">
<!-- Bootstrap Icons -->
<link href="https://cdn.jsdelivr.net/npm/bootstrap-icons@1.11.0/font/bootstrap-icons.css" rel="stylesheet">

<!-- Custom CSS for API-specific styling -->
<style>
.api-section {
border-left-width: 3px;
}

.api-section.blue-accent {
border-left-color: #0d6efd;
}

.test-instruction {
font-size: 0.75rem;
color: darkred;
font-weight: 500;
}
</style>
</head>
<body>
<main role="main" aria-label="[COMPONENT_NAME] API test samples">
<div class="container-fluid py-4">
<h1 class="display-5 text-dark mb-4">UI5 [COMPONENT_NAME] Component API Samples</h1>

<!-- [AI_REPLACE_START: API Cards] -->
<!-- Create one card for each API element (property, slot, event, method) from the component -->
<!-- Each card follows this exact structure: -->

<div class="card border-start api-section blue-accent mb-4">
<div class="card-body">
<h2 class="h6 fw-bold mb-3">[API_NAME] API</h2>
<div class="text-muted fst-italic mb-3">[Description of what this API does]</div>
<div class="bg-light rounded p-3">
<div class="d-flex flex-wrap gap-3 align-items-center" data-cy-acc-container-id="[32_char_hex_id]">
<!-- Add component examples here demonstrating the API -->
</div>
<!-- Optional: Add test-instruction div only if manual testing is needed -->
<!-- <div class="test-instruction">Test instructions: [How to test]</div> -->
</div>
</div>
</div>

<!-- [AI_REPLACE_END] -->
</div>
</main>

<!-- [AI_REPLACE_START: JavaScript] -->
<!-- Add JavaScript only if needed for interactive demos (events, accessibilityAttributes, etc.) -->
<script>
// Example: Event listeners, accessibilityAttributes setup
</script>
<!-- [AI_REPLACE_END] -->

<!-- Bootstrap JS Bundle -->
<script src="https://cdn.jsdelivr.net/npm/bootstrap@5.3.2/dist/js/bootstrap.bundle.min.js"></script>
</body>
</html>
```
20 changes: 20 additions & 0 deletions .github/components-list.instructions.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,20 @@
## Component List For Accessibility Test Page Generation

From Main Components:

- DynamicDateRange

From Fiori:

- DynamicSideContent
- Timeline
- TimelineGroupItem
- TimelineItem
- FilterItem
- FilterItemOption
- SortItem
- ViewSettingsDialog

From AI:

- Button
137 changes: 137 additions & 0 deletions API_Pages_Framework.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,137 @@
# Step-by-step framework for Team Balkan Components – API Pages

Below is the exact framework that we used, to generate API Test Pages of Team Balkan's web components.

## Initial Setup and Prompt

### Initial Setup

- First we set-up a `components-list.instructions.md` file (we listed in a bulleted list all of the components Claude should iterate);
- Secondly we created another file with all of the instructions from the ui5-webc-acc-hub (but a little tweaked), in our case it was named `acc-test-page-generation.instructions.md` (included in the Prompt below);

### Initial Prompt

#### We instruct the AI to FIRST generate one-or-two pages, just to make sure we're on the same page.

```prompt
I need you to create a comprehensive API test page for ALL of the components listed in #file:components-list.instructions.md file.

Follow the instructions strictly. Let’s start with the first 2 components. Proceed step-by-step, following the instruction file, be concise and DO NOT overengineer.
Use #file:Avatar_ACC_APIs.html and #file:Avatar_ACC_Standards.html files as examples/refferences on how the pages are expected to be. You can also refer to the template provided in the #file:acc-test-page-generation.instructions.md .

Before implementing anything always double-consult with the instruction files. If uncertain for anything, better ask, instead of blindly making decisions. Proceed with the first two components.
```

**Note:** Make sure to actually link the files in the prompt.

After that if the result were good, we instruct the Assistant to continue with the same patterns (we nailed it first try)

```prompt
Perfect! Continue with all of the components listed in the #file:components-list.instructions.md file. The bar and the button are already implemented. As in the previous task, follow the instructions strictly. Proceed step-by-step, following the instructions and be concise, DO NOT overengineer.

Use the #file:Avatar_ACC_APIs.html , #file:Avatar_ACC_Standards.html , #file:Button_APIs.html files as examples, refferences. Refer to the template provided in the #file:acc-test-page-generation.instructions.md file. Before implementing anything, always double-check with the instruction files. if uncertain for ANYTHING ask, instead of blindly making decisions. Proceed with the remaining components.
```

**Note**: Again, make sure to link the files in the prompt manually.

### Avoid hallucinations

A good practice to avoid hallucinations if you have components with large amount of lines, context or else, is to process the components in batches (we did it in batches of 6 to 10), depending on the complexity of the components.

So in short: every 6 to 10 components → New Chat → Prompt including something like:

```prompt
I need you to create a comprehensive API test page for ALL of the REMAINING components listed in #file:components-list.instructions.md file.

Follow the instructions strictly. Proceed step-by-step, following the instruction and be concise, do not overengineer.
Use #file:Bar_APIs.html, #file:Calendar_APIs.html, #file:ColorPalette_APIs.html and all of the attached files as examples/refferences on how the pages are expected to be. You can also refer to the template provided in the #file:acc-test-page-generation.instructions.md.

Before implementing anything always double-consult with the instruction files. If uncertain for anything, better ask, instead of blindly making decisions. Please proceed with ALL of the remaining components. You can split them in Batches to avoid token and context leakage. MAKE SURE TO NOT INCLUDE ANY DEPRECATED PROPERTIES AND TO INCLUDE ALL OF THE PROPERTIES (EXCEPT THE DEPRECATED ONES) in the test pages.
```

### Error handling

As expected, not everything is always perfect from the first try, so we can encounter some errors, like imports, missing props and so on.

So a good way to handle errors (or at least from my experience) is to use semantic prompts. What I mean by that is structure your prompts, in a semantic way like emphasizing end/start of the error message, giving context or tips what could be the cause of the error, hints and so on. For example:

#### Error 1

Good! Unfortunately in the APIs page of the Date Components we are unable to see anything, and we've got the following error in the console:

```error
LocaleData.ts:98 Uncaught (in promise) Error: CLDR data for locale en is not loaded!
```

#### Error 2

We are still unable to see the components (the calendar). You can check the #file:Calendar.html file for hints, or #file:Calendar.ts for more insights on the CLDR.

```error
LocaleData.ts:98 Uncaught (in promise) Error: CLDR data for locale en is not loaded!
at getLocaleData (LocaleData.ts:98:9)
at Object.loadResource (LoaderExtensions.ts:10:9)
at getOrLoad (LocaleData.js:2520:55)
at getData (LocaleData.js:2572:13)
at new constructor (LocaleData.js:57:23)
at new LocaleData (LocaleData.ts:6:1)
at getCachedLocaleDataInstance (getCachedLocaleDataInstance.ts:9:21)
at get _primaryCalendarType (DateComponentBase.ts:129:22)
at Calendar.getFormat (DateComponentBase.ts:246:24)
at get _selectedDatesTimestamps (Calendar.ts:355:56)
```

## Manual AXE Testing

After all of the errors are handled, all APIs, samples and whatnot are here and our API Pages look good, we can now proceed to the acc part.

### What we did
1. We manually traverse through our API pages and check for issues with the AXE tool
2. All individual issues summarised and structured in Notes, .md file or else
3. The file we did was structured in format like:

```md
# Accessibility Issues Report

Files included in the report:

- Component X;
- Component Y;
- Component Z;

## Overview
This document contains accessibility issues found across multiple API documentation pages.

## Component X

### Issues 1 of N (found with AXE)

**Element Location:**
```code
#element[class], .class[attr]
```

**Element Code:**
```html
#element[class], .class[attr]
```

**Problems**
- Element does not have text that is visible to screen readers
- aria-label attribute does not exist or is empty
- aria-labelledby attribute does not exist, references elements that do not exist or references elements that are empty
- Element has no title attribute

**To solve this problem, you need to fix at least (1) of the following:**
- Element does not have text that is visible to screen readers
- aria-label attribute does not exist or is empty
- aria-labelledby attribute does not exist, references elements that do not exist or references elements that are empty
- Element has no title attribute

**Issue Details:**
- **Found:** Automatically
- **Impact:** serious
- **Categories:** cat.aria, wcag2a, wcag412, TTv5, TT6.a, EN-301-549, EN-9.4.1.2, ACT
```
4. Then we gave the document to the AI to fix the issues (if they were sample issues)
5. Most (if not all) of them were component level ACC issues, at least in our case.
Loading
Loading