Feedback Page
Technical Description
HTML structure: The page is organised into three main parts inside the
.feedback-wrapper container. These are the intro panel, the programme directory,
and the reviews with feedback form section. I used semantic elements such as
<main>, <section>, <article>,
<form>, <fieldset> and <label>
so the page stays clear and easier to navigate. The programme directory is built using repeated
.program-card articles, while the form is divided into grouped fieldsets for
personal details and visitor feedback.
CSS design: The page styling follows the shared dark glass look used across the
website. I reused card based styling for the intro panel, directory, reviews, rating summary and
form so the page feels visually connected. The programme section uses
.program-grid for a two column layout, and the reviews and form area uses
.reviews-grid. I also added a scrollable
.directory-scroll-box with a custom thin scrollbar so the directory can hold more
content without making the page too long. Small hover effects on programme cards and review cards
make the page feel more interactive.
JavaScript: This page uses page-specific JavaScript to make the feedback form interactive and
easier to use. The script runs after DOMContentLoaded so all form elements are available before validation begins. It updates
the character counter for the comments box in real time, checks required fields, validates email and telephone input, prevents past dates from being selected, and displays clear success
or error messages in the status box. I kept the validation logic in separate helper functions so the script stays easier to read and manage.
Design and implementation rationale: I wanted this page to feel practical rather
than just decorative, so I combined browsing content with a usable form. The directory cards
introduce support ideas linked to SDG 16 such as legal aid, dialogue, mediation and inclusive
help points. The rating summary and review cards make the section feel more realistic, while the
validated form gives the user a clear place to respond. In JavaScript, the form uses
DOMContentLoaded, addEventListener(), and separate validation checks
for required fields, email format, telephone format, future date selection, character count, and
status messages. This kept the logic easier to explain and maintain.
Accessibility
-
Semantic structure: The page uses headings, sections, articles, fieldsets
and labels so content is grouped properly and form controls are clearly connected to their
text labels.
-
Keyboard access: The form controls, buttons and links are all native HTML
elements, so they can be reached and used through keyboard navigation without extra scripts.
-
Alt text: Every programme card image includes descriptive
alt text so the visual meaning is not lost for screen reader users.
-
Feedback support: The status box uses
aria-live="polite" so success or error messages can be announced after form
submission.
-
Readable layout: The page keeps good contrast between text and background,
and the layout stacks into one column on smaller screens for easier reading.
Link to the validation page
Link to the page
Team Page
Technical Description
HTML structure: The team page is built around a centred intro section and a
.team-grid that contains four individual .team-card blocks. Each card
includes a profile image, team member name, short role label, and an overlay
.extra-info panel with more details. I used a simple repeated structure for each
member so the page stays consistent and easy to update.
CSS design: The layout uses a two column grid on larger screens and switches to
one column on smaller screens through a media query. I used gradient borders, rounded cards,
soft shadows and circular profile images to match the visual style of the rest of the site.
The hover and focus effect on .team-card lifts the card slightly and reveals the
hidden overlay using opacity. This gives the page some interaction without needing JavaScript for
the card behaviour itself.
Design and implementation rationale: I wanted the team page to introduce each
member clearly while still feeling engaging. Instead of placing all information directly on the
card, I used an overlay panel so the page stays cleaner at first view and reveals more details on
hover or keyboard focus. This helps balance presentation and information. I also kept the page
text short and direct because the main purpose of this page is identification of roles and page
responsibilities, not long descriptions.
Accessibility
-
Keyboard interaction: Each card uses
tabindex="0", so keyboard users can focus the cards and reveal the extra
information without using a mouse.
-
Focus visibility: The page includes a visible
:focus-visible outline to help users see which card is active.
-
Alt text: Each profile image includes descriptive portrait based
alt text.
-
Clear page structure: The heading hierarchy is simple and the team section
uses a clear label so assistive technology can identify the purpose of the group.
Link to the validation page
Link to the page
Content Page (Student 3)
Technical Description
HTML structure: The content page is written as a single article inside the
.article-container. It includes a main heading, an intro paragraph, a table of
contents, a highlight box, and four main content sections with their own headings. I used
semantic elements such as <article>, <nav>,
<section>, <h2>, <h3> and
<ul> so the article is easier to scan and easier to navigate through anchor
links.
CSS design: The page follows a glass style layout with
backdrop-filter, transparent backgrounds, subtle borders and soft shadows. The
table of contents and highlight box use separate accent colours to visually break the article
into useful entry points. Images use the .styled-image class with hover effects,
and the quote panels use a gold border to stand out from the normal body text. I also added a
fixed .back-to-top-css link so users can move back to the start of the article
more easily.
Design and implementation rationale: My aim was to make the article feel easier
to read than a plain long page of text. The table of contents helps users jump to sections, the
summary box gives a quick overview, and the section layout breaks the topic into manageable
parts. The topic itself focuses on access to justice, barriers people face, the role of digital
tools, and what communities and individuals can do. This supports the wider SDG 16 theme of the
group project while still keeping my page focused on one clear issue.
Accessibility
-
Semantic structure: The article uses proper headings, sections and a
navigation block for the table of contents, which improves structure for both readers and
assistive technologies.
-
Internal navigation: The table of contents links to section ids, and
scroll-padding-top and section spacing help stop headings from being hidden
behind the fixed header.
-
Alt text: All article images include descriptive
alt text related to justice, legal support and digital access.
-
Back to top link: The fixed button uses
aria-label="Go to top" so its purpose is clearly communicated.
-
Readable contrast: The muted text and accent colours are used against dark
surfaces in a way that keeps the page readable.
Link to the validation page
Link to the page
Challenges and Lessons Learned
Challenge 1 — Keeping the Feedback Page Detailed Without Making It Too Long
The main issue on the feedback page was balancing content and usability. I wanted the page to
include enough programme cards, reviews and form fields to feel complete, but if everything was
placed in a normal long layout the page became heavy to scroll. I solved this by keeping the
programme cards inside a dedicated .directory-scroll-box with a custom scrollbar.
This let me keep the directory useful without pushing the form too far down the page. It also
taught me that layout decisions can directly affect how practical a page feels.
Challenge 2 — Making the Team Cards Interactive but Still Clear
On the team page, I wanted each card to show more information without crowding the front view.
My solution was to use an overlay panel that appears on hover and focus. The challenge was making
sure the transition felt smooth while keeping the text readable and the card still accessible for
keyboard users. Adding tabindex="0" and a visible focus style helped solve that.
This reminded me that interaction should not depend only on mouse hover.
Challenge 3 — Structuring the Content Page for Easier Reading
The content page covered a serious topic, so one challenge was making the article informative
without it turning into a block of text. I addressed this by breaking the article into sections,
adding a table of contents, using summary points, and placing images between the text where they
supported the topic. This improved flow and made the page easier to follow. I learned that good
structure can improve understanding just as much as the written content itself.
Compliance
The pages I created were designed in a way that reflects Janet guidance for responsible web publishing in an educational context.
My content is appropriate for academic use, relevant to the SDG 16 theme, and does not include harmful, misleading, or inappropriate material.
- Appropriate and ethical content: All page content was written for an educational purpose and kept suitable for a university coursework website.
- Accessibility: I used semantic HTML, descriptive alt text, keyboard-friendly elements, visible focus styles, and readable contrast to support inclusive access, in line with accessibility good practice expected for educational websites.(W3C, 2024)
- Responsible data use: My feedback form only performs client-side validation and does not store or transmit personal data to a server, so unnecessary collection of user data is avoided.
- Secure and responsible development: The pages are static and do not include malicious code, harmful scripts, or unsafe behaviour that could affect users or systems.
- Copyright and academic integrity: External images and resources were selected carefully and credited in the references section, helping ensure responsible use of third-party material.
Group Meetings and Individual Contribution Log
The following log keeps the same table structure and records my contribution to the group work
across the project.
| Group Meetings and Contribution Log |
| Meeting |
Date & Time |
Format |
Objective |
Attended |
Your Individual Contribution |
| 1 |
12 Feb 2026 |
Face-to-Face |
Agree on SDG topic and assign roles. |
Yes |
I confirmed my role as Student 3 and agreed to develop the Feedback page,
Team page and my own content page for the project. |
| 2 |
19 Feb 2026 |
Online (Discord) |
Finalise theme and wireframe pages. |
Yes |
I shared ideas for a feedback page that combined a programme directory,
community reviews and a validated form so the page would feel more useful and interactive. |
| 3 |
26 Feb 2026 |
Hybrid |
Merge core pages and test routing. |
Yes |
I integrated feedback.html, team.html and
content_ST3.html into the shared project and checked that the
navigation links, footer links and student pages connected correctly. |
| 4 |
05 Mar 2026 |
Online (Discord) |
Team code review and bug fixing. |
Yes |
I improved the feedback form validation, checked form error messages, and adjusted
the layout so the programme directory stayed scrollable without affecting the rest of the page. |
| 5 |
12 Mar 2026 |
Face-to-Face |
Content review and alignment. |
Yes |
I revised the access to justice article, improved the internal navigation, and made
sure the writing style and visual design stayed aligned with the overall team website. |
| 6 |
18 Mar 2026 |
Hybrid |
Final W3C validation and packaging. |
Yes |
I ran my pages through validation checks, corrected smaller HTML issues, reviewed
accessibility details such as alt text and focus behaviour, and prepared the final evidence
for submission. |
References
The main sources consulted while creating my pages are listed below in Harvard style.
