WDD-231---Web-Frontend-Development-I

Learning Contract c01: Accessible Personal Portfolio Home Page

Student: Joshua Merrell
Date: November 4, 2026
Target review date: November 5, 2026

Peer review: Peer Review r01 — not yet created
Evidence: Evidence index c01

Primary competency and planned slices

My primary competency is Semantic and accessible HTML. For this contract, I will work on all four slices:

• Choose HTML elements according to meaning and structure rather than appearance.
• Create headings, landmarks, navigation, forms, labels, buttons, and links that make sense to assistive technology users.
• Support keyboard navigation, visible focus, readable text, useful alt text, and appropriate names for interactive controls.
• Check a page with keyboard-only navigation, browser tools, and an accessibility checker.

I am deferring these slices from my primary competency, if any:

• None.

Related supporting slices from other competencies, if needed:

• None.

Competencies or slices I am choosing to work on later:

• Other competencies, including advanced CSS, JavaScript, APIs, state, and deployment, will be addressed in later contracts unless they are needed only for basic project setup.

This contract focuses primarily on semantic and accessible HTML. It does not certify the whole competency; certification happens in an instructor or TA pass-off after peer review of every slice in that competency.

My starting point

I have basic experience with HTML, CSS, and JavaScript. I can create a basic web page, but I need more practice choosing HTML elements for their meaning and checking whether a page is usable for people who navigate with a keyboard or assistive technology.

Question guiding my learning

How can I structure a portfolio so it is usable and meaningful for people using keyboards or assistive technology?

My learning plan

Resources I will use:

• WDD 231 Competency Guide
• W3C WAI Page Structure Tutorial
• MDN: HTML as a basis for accessibility
• MDN: Accessibility tooling and assistive technology
• WAVE Web Accessibility Evaluation Tool
• W3C Markup Validation Service

What I will build or practice:

I will build the home page for a personal portfolio in projects/personal-portfolio/. The page will include my name, a short introduction or hero, and a small list of projects I have participated in, along with the skills demonstrated by each project. This will start off as a demo with very little content so I can pass this off a.s.a.p. I will structure the page with meaningful HTML and make its content and interactions understandable to keyboard users and assistive technology users.

Steps:

1. Plan the page content and identify the appropriate document structure, landmarks, headings, navigation, image description, links, and any controls before writing the page.
2. Write the home page HTML only.
3. Test the page with keyboard-only navigation, browser inspection tools, zoom or text enlargement, WAVE, and the W3C Markup Validation Service.
4. Record progress in evidence/c01/.
5. Prepare to explain my HTML decisions and demonstrate the page to a peer.

First milestone and due date: A working portfolio home page ready for keyboard, zoom, browser-tool, and WAVE checks by November 5, 2026.

How I will challenge my understanding:

Before testing, I will predict whether a keyboard-only user can move through the page in a sensible order, see where focus is, understand each link or control, and reach the main content without confusion. I will then test with Tab, Shift+Tab, Enter, and Space, inspect the document structure in browser tools, enlarge text or zoom the page, run WAVE, and validate the markup with the W3C Markup Validation Service. I will record screenshots of my progress in evidence.

Evidence of learning

I will submit or demonstrate:

• The working home page and relevant files in projects/personal-portfolio/.
• An explanation of why I chose the HTML elements, page landmarks, heading structure, image alternative text, and link or control names.
• Notes or screenshots from keyboard-only navigation, browser inspection, zoom or text enlargement, WAVE checks, and W3C markup validation.
• At least one debugging or investigation note describing the expected behavior, actual behavior, hypothesis, change, and verification.
• A small transfer challenge, such as explaining how I would adapt the structure for another portfolio project or add a new section without breaking the heading and landmark structure.

I will know I am ready for peer review when:

• All four planned slices are represented in the page and I can explain the relevant decisions.
• I have completed keyboard, browser-tool, zoom or text-enlargement, WAVE, and W3C markup validation checks and recorded the results.
• I have addressed or clearly documented important findings and can explain any remaining uncertainty.

What my evidence does and does not establish:

This evidence will show what I can explain and demonstrate in this portfolio home page. It will not by itself certify the entire Semantic and accessible HTML competency or prove that the page works for every assistive technology or user situation.

Support and risks

Help I may need and when I will ask:

I will ask for help understanding specific accessibility findings, especially what a WAVE error or warning means and how to investigate it. I also need guidance deciding what content belongs on the page. I will ask focused questions after I have identified the relevant element, observed the behavior, and recorded what I expected to happen.

Main risk and my response:

My main risk is trying to include too much content before the review. I will keep the first increment small: one home page, a short introduction, and a small project list. I will prioritize clear structure and evidence over adding extra features.

AI use, if applicable

I may use AI to analyze the page I wrote, explain accessibility concepts, help interpret a specific issue, and suggest questions or improvements. AI must not create or complete code for the four slices in this contract.

When I use AI, I will record:

• What I asked and whether I requested analysis, explanation, or suggestions rather than code.
• Which suggestions I used or rejected and why.
• How I checked the result independently using course materials, documentation, keyboard testing, browser tools, WAVE, or another experiment.
• How I can explain the final HTML and accessibility decisions without relying on the AI conversation.

Project and evidence locations

• Project scaffold: projects/personal-portfolio/
• Evidence folder: evidence/c01/
• Planned peer review: November 5, 2026