Colorblind Accessibility Function Test

assignment-1/ai-test-cases.md

@@ -0,0 +1,55 @@
+Valid Hex Color Pairs
+
+Red (#FF0000) vs Green (#00FF00) → False (should fail, indistinguishable for red-green colorblind)
+
+Red (#FF0000) vs Blue (#0000FF) → True (should pass, distinguishable)
+
+Green (#00FF00) vs Blue (#0000FF) → True (should pass, distinguishable)
+
+Dark Red (#8B0000) vs Dark Green (#006400) → False (should fail)
+
+Red (#FF0000) vs Yellow (#FFFF00) → True (yellow has no green component, distinguishable)
+
+Purple (#800080) vs Brown (#A52A2A) → True (different color families)
+
+Two shades of blue: #0000FF vs #1E90FF → True (distinguishable by brightness)
+
+Identical Colors (Edge Cases)
+
+Red (#FF0000) vs Red (#FF0000) → False (identical, not distinguishable)
+
+Green (#00FF00) vs Green (#00FF00) → False (identical)
+
+Blue (#0000FF) vs Blue (#0000FF) → False (identical)
+
+Boundary and Tricky Cases
+
+Almost identical reds: #FF0000 vs #FF1000 → False (too similar)
+
+Red (#FF0000) vs Pink (#FFC0CB) → True (pink has less red intensity, likely distinguishable)
+
+Lime (#32CD32) vs Forest Green (#228B22) → False (both green shades)
+
+Orange (#FFA500) vs Red (#FF0000) → Orange contains red and green signals, may be problematic → False
+
+Invalid Inputs
+
+Empty string "" vs "#FF0000" → Should raise error or return False
+
+Invalid hex: "#GGGGGG" vs "#FF0000" → Should raise error or return False
+
+Missing hash: "FF0000" vs "00FF00" → Should raise error or return False
+
+Wrong length: "#F00" vs "#0F0" → Should raise error or return False
+
+Non-string input: 123 vs "#FF0000" → Should raise error or return False
+
+Lowercase vs uppercase mismatch: "#ff0000" vs "#00FF00" → Should handle case-insensitively, return False
+
+Additional Edge Cases
+
+White (#FFFFFF) vs any color → True (white is distinct)
+
+Black (#000000) vs any color → True (black is distinct)
+
+Very dark green (#002200) vs black (#000000) → May be hard to distinguish → False

assignment-1/colorblind_utils.py

@@ -0,0 +1,28 @@
+def is_red_green_safe(hex_color1, hex_color2):
+    """
+    Check if two colors are distinguishable for red-green colorblind users.
+
+    This is a simplified approximation. Real accessibility tools use more
+    sophisticated algorithms, but this works for demonstration.
+
+    Args:
+        hex_color1: Hex color string like "#FF0000" for red
+        hex_color2: Hex color string like "#00FF00" for green
+
+    Returns:
+        True if the colors are likely distinguishable, False if they may
+        appear too similar to someone with red-green colorblindness.
+    """
+    # This is a placeholder. In reality, you would convert to a color space
+    # like LAB and calculate perceptual distance.
+    # For now, just return True for red vs blue and False for red vs green.
+
+    red = "#FF0000"
+    green = "#00FF00"
+    blue = "#0000FF"
+
+    if (hex_color1 == red and hex_color2 == green) or (hex_color1 == green and hex_color2 == red):
+        return False
+    if (hex_color1 == red and hex_color2 == blue) or (hex_color1 == blue and hex_color2 == red):
+        return True
+    return True

assignment-1/critique.md

@@ -0,0 +1,41 @@
+# Critique of AI-Generated Test Cases
+
+## What I Would Change
+
+The AI assumes the function handles invalid inputs gracefully by returning False or raising an error. My current placeholder function does not. It would crash on an empty string or a malformed hex code. I would change the function to validate inputs first, then write tests that expect proper error handling rather than guessing behavior.
+
+The AI also assumes identical colors should return False. My current placeholder returns True for identical colors unless they are exactly red vs green. That is wrong. Two identical colors are never distinguishable. I would fix the function to return False for any identical input pair. I would also add a test case for green vs green and blue vs blue to catch this bug.
+
+## What I Would Remove
+
+The AI includes test cases for very dark green vs black. That is a valid accessibility concern, but my simplified function does not calculate perceptual distance. It only checks a hardcoded list. Those test cases would fail even though the function is working as designed for its current scope. I would remove them until the function implements real color space conversion.
+
+The orange vs red test case makes a claim about orange containing red and green signals. That may be true in some color models, but my function does not know that. Remove.
+
+## What I Would Add
+
+The AI included invalid hex inputs like `#GGGGGG` in the test cases, which is good. But the AI assumed the function would handle them gracefully by returning False or raising an error. My function does neither. It would crash. I would add a test case that expects an exception or a False return value for `#GGGGGG`, and I would change the function to validate inputs before attempting to process them.
+
+The AI missed testing for identical colors beyond red vs red. The AI included red vs red, but did not include green vs green or blue vs blue. I would add test cases for green vs green expecting False and blue vs blue expecting False. This would catch the functional bug where my function currently returns True for identical colors that are not red.
+
+The AI missed testing for different hex formats. Some functions accept `#FFF` as shorthand for `#FFFFFF`. Others accept `FFF` without the hash. I would add test cases for three-digit hex and hashless formats if the function supports them.
+
+The AI did not test for case sensitivity. My function should treat `#ff0000` the same as `#FF0000`. I would add test cases for lowercase and mixed case inputs.
+
+The AI did not ask what the function should do when one color is valid and the other is invalid. I would add test cases for that scenario.
+
+The AI did not test performance. Not relevant for this simple function, but for a real accessibility tool processing many color pairs, I would add a test that ensures the function runs quickly.
+
+## Bug Classification
+
+The issues I identified in my function fall into two categories from the slides.
+
+Functional issue: The function fails on identical colors and invalid hex inputs. It does not do what it is supposed to do. A user relying on this function would get incorrect results. This is a functional bug.
+
+Requirements issue: The function currently has no specification for what counts as "distinguishable." The AI assumed perceptual distance, but my function only checks a hardcoded list. Without clear requirements, I cannot say whether the function is correct or not. This is a requirements bug.
+
+Neither issue is a design issue. The code is simple and readable. The problem is that it does not meet requirements because the requirements do not exist.
+
+## Summary
+
+The AI generated a reasonable starting set of test cases. It understood the domain and identified edge cases like identical colors and red-green pairs. But it assumed a level of sophistication my function does not yet have. The critique process revealed that my function needs input validation, proper handling of identical colors, and clearer documentation of its limitations. The AI is good at brainstorming test ideas. The human is needed to match those ideas to what the code actually does.

assignment-1/project-selection.md

@@ -0,0 +1,5 @@
+# Project Selection
+
+I chose a colorblind accessibility utility function called `is_red_green_safe()`. The function takes two hex color codes and returns whether they are likely distinguishable for someone with red-green colorblindness.
+
+This is a real problem I care about. I have deuteranomaly, so I cannot distinguish red and green myself. Building and testing accessibility tools directly relates to my own experience as a user and developer.