Skip to content

Project: Create an accessible portfolio

Create a portfolio that introduces your work, explains at least three projects, and gives a visitor a safe way to make contact. The visitor goal stays the same at every supported level. Your current course level determines how you structure and implement the portfolio.

What you will practice

  • Select and organize project information for a specific visitor.
  • Build an accessible and responsive path through a portfolio.
  • Apply the technical methods and verification practices from your current course level.

The portfolio is for a junior web developer, designer, or content specialist who needs to present selected work. You can represent yourself or create a fictional professional profile.

The portfolio must help a visitor answer these questions:

  • Who does this person help, and what type of work do they do?
  • Which projects show relevant skills?
  • What problem did each project address?
  • What did the person contribute?
  • How can a visitor make contact without seeing private information?

Use fictional contact details or a safe contact link. Do not publish a private address, telephone number, personal email address, client secret, or login credential.

Starting point

Before you start

  • The lessons and tools used in your current course level.
  • Content for at least three real or fictional projects.
  • A code editor and browser, plus the framework tools required by your selected level.
  • A parent course folder where you can create one dedicated project folder or CMS evidence folder.
Current state
You have project ideas or examples, but the portfolio structure and implementation do not need to exist yet.
First action
Open your level section below. Create a short content outline with an introduction, three projects, an about section, and a contact route.
First checkpoint
The portfolio opens and shows the professional role, one-sentence introduction, and titles of all three projects.
Help trigger
Open the assistance section or ask for help when you cannot identify the next content item, file, component, or test needed for the current checkpoint.

Requirements

The required assignment is complete when every applicable criterion below is met.

Required content and visitor path

  • The opening content states a professional role and the type of work presented.
  • The portfolio presents at least three projects with a title, short summary, contribution, and relevant skill or tool.
  • An about section gives relevant professional context without requiring private information.
  • A navigation route connects the introduction, project work, about information, and contact route.
  • The contact route uses fictional details or a safe external profile link.

Accessibility and responsive behavior

  • The page uses descriptive headings and meaningful link text.
  • Each project image has alternative text that describes its relevant content, or an empty alt attribute when the image is decorative.
  • Every link and control works with a keyboard and has a visible focus state.
  • Required content remains readable without horizontal page scrolling at a 320px viewport and at 200% browser zoom.
  • Project categories and current states do not depend on color alone.

Project workspace and version control

  • Create one dedicated project folder before implementation. Keep unrelated exercises and repositories outside it.
  • For a source-code implementation, make the project folder a Git repository on main and connect it to its own private GitHub repository as origin.
  • Commit coherent working checkpoints, inspect staged changes, push the final verified state, and finish with a clean working tree.
  • For a CMS implementation, use one dedicated CMS workspace and a local evidence folder for plans and restorable exports. Use Git for source or evidence files when the selected level requires it, and never commit credentials or private data.

Design freedom

  • Choose the professional profile, project subjects, written content, images, color palette, typefaces, and visual layout.
  • Use one page or several pages unless your selected level requires a specific routing approach.

Out of scope

  • The required project does not need a working contact form, authentication, private analytics data, or a live deployment.
  • The project does not require implementation rules from another course level.
  • Optional extensions do not affect whether the required project is complete.

Complete the shared requirements and one level section. The other sections are not additional requirements.

Provisional expected effort: 6–10 hours for the required path. This range includes content preparation, implementation, support, debugging, verification, and re-entry. Optional extensions are not included.

New and reused: Reuse semantic HTML, responsive CSS, image preparation, and validation. Combine these skills in a multi-section portfolio.

First action: Create index.html and styles.css. Add the professional role, introduction, and three project headings to index.html before you begin the visual layout.

  • Build the portfolio with semantic HTML and CSS.
  • Use landmarks and sections that match the content purpose.
  • Use a list, grid, or repeated article structure for the three projects.
  • Use a responsive layout that changes without hiding required project information.
  • Validate the HTML and correct errors that affect structure or accessibility.
  • Do not use JavaScript or a framework for the required path. This level assesses HTML and CSS.

The project is complete for Level 1 when the shared requirements pass, the complete portfolio is available through HTML and CSS, the page passes the viewport and zoom checks, the HTML structure validates, and you can explain two semantic or responsive-design choices.

Provisional expected effort: 8–14 hours for the required path. This range includes content preparation, implementation, support, debugging, verification, and re-entry. Optional extensions are not included.

New and reused: Reuse responsive HTML and CSS. Add a progressively enhanced project filter, clear interface states, and an analytics plan.

First action: Add all project cards as visible HTML. Give each project one category such as frontend, design, content, or testing before you write the filter code.

  • Add controls that filter project cards by category with JavaScript.
  • Keep every project available when JavaScript is unavailable.
  • Show the selected category with visible text or state in addition to color.
  • Announce the number of matching projects when the filter changes.
  • Respect prefers-reduced-motion if the interface uses motion.
  • Write a short analytics plan that identifies two useful measurements and the question each measurement answers. Real tracking is not required.

The project is complete for Level 2 when the shared requirements pass, the project filter works with pointer and keyboard input, all projects remain available without JavaScript, selected and empty states are clear, reduced-motion behavior passes, and the analytics plan contains two relevant measurements.

Provisional expected effort: 10–18 hours for the required path. This range includes content preparation, implementation, support, debugging, automated testing, verification, and re-entry. Optional extensions are not included.

New and reused: Reuse accessible interface and responsive-design skills. Add structured project data, component boundaries, routing, and automated tests.

First action: Create the project with the framework used in your current course work. Render one project card from a structured project-data object or file.

  • Build the portfolio with the framework and routing approach used in your current course work.
  • Store project content separately from the components that render it.
  • Use components with clear responsibilities for navigation, project summaries, project details, and contact information.
  • Provide a stable URL or route for each full project description.
  • Add at least one automated test for a component, data transformation, route, or filtering behavior that matters to the visitor path.
  • Use version control and confirm that the production build completes without errors.
  • A backend, database, and authentication system are not required.

The project is complete for Level 3.1 when the shared requirements pass, structured project data renders through clear components and routes, the required automated test passes, the repository records the implementation history, and the production build completes without errors.

  1. Add the professional role and introduction.
  2. Add all three project summaries and their full required information.
  3. Add the about information and safe contact route.
  4. Connect the navigation and follow the complete visitor path in a browser.

A visitor can identify the professional role, open or read all three projects, understand the contribution to each project, and reach the safe contact route.

Checkpoint: The complete portfolio content is available

What now works
The professional introduction, three projects, about information, navigation, and contact route are present.
What remains
Complete and verify the implementation requirements for the selected course level.
Next action
Return to the selected level section and test its first required technical behavior.
If it does not work
If content is missing, compare the page with the five visitor questions in the project brief and add one missing answer at a time.

Complete and verify the selected implementation

Section titled “Complete and verify the selected implementation”

Complete the implementation requirements for your current level. Keep the shared visitor path working while you add the required structure, interaction, or application architecture.

Run every check in the selected level definition of done. Correct the first failed check, then repeat the complete portfolio path.

Checkpoint: The selected level implementation works

What now works
The shared portfolio and the implementation requirements for one course level pass their stated checks.
What remains
Complete the final self-check and prepare the project for submission.
Next action
Run the self-check from top to bottom and record any failed item before changing the project.
If it does not work
If several checks fail, restore the first shared visitor behavior that fails before testing level-specific behavior again.

The project brief and requirements remain visible above. Open one assistance level when you want more structure.

Assistance 1 — Identify the current portfolio target

Keep one visitor question and one course level active. Work in the content item, file, or component that owns the first visitor answer that is missing.

Assistance 2 — Use a bounded project-summary structure

For each project, write four fields before styling: title, problem, contribution, and relevant skill or tool. Use the same structure for all three projects.

Assistance 3 — Follow the portfolio subgoals

Use this order: add the introduction, complete the three project summaries, add about and contact information, connect navigation, complete the selected level implementation, then run the final checks.

Self-check

Complete these checks against the required result.

  1. Confirm that the opening content states the professional role and type of work.
  2. Open or read each project and confirm that its problem, contribution, and relevant skill or tool are present.
  3. Follow the navigation to the about information and safe contact route.
  4. Use only the keyboard to operate every link and control and confirm that focus remains visible.
  5. Check the portfolio at a 320px viewport and at 200% browser zoom without horizontal page scrolling.
  6. Run the checks in the selected level definition of done. Requirements from the other levels do not apply.
  7. Confirm that the portfolio contains no private contact information, login credentials, or client secrets.

Stop after a checkpoint passes. Record what works, what remains, the exact next action, and any required server, browser, file, or test state. Use that note as the first action when you resume.