Update to Interactify Beta

{
  "description": "Write content for Interactify's H5P activities so they're usable by people with visual, motor, cognitive, or language-related access needs - not through code changes (H5P's own runtime already handles keyboard navigation and screen reader labeling), but through the actual wording and answer-matching choices made when generating content.",
  "included_files": [],
  "name": "accessible-interactive-design",
  "skill_md_contents": "---\nname: accessible-interactive-design\ndescription: Write content for Interactify's H5P activities so they're usable by people with visual, motor, cognitive, or language-related access needs - not through code changes (H5P's own runtime already handles keyboard navigation and screen reader labeling), but through the actual wording and answer-matching choices made when generating content.\n---\n\nH5P's runtime libraries already provide real accessibility infrastructure - keyboard\nnavigation, ARIA labeling, screen-reader announcements - without any extra effort on your\npart. This skill is about the part that infrastructure *can't* fix: the actual words and\nanswer logic chosen when generating content. Getting that wrong creates a real barrier even\nthough the underlying player is fully accessible.\n\n## Accept reasonable answer variation, not just one exact phrasing\n\nRequiring a single exact spelling or phrasing is a real access barrier - for dyslexic\nlearners, English language learners, and anyone using assistive input, not just a\nconvenience issue.\n\n- **Fill in the Blanks**: use the `/` syntax to accept genuine alternate spellings or\n  phrasings for the same blank, e.g. `*colour/color*` or `*labour/labor*`, whenever more\n  than one answer is legitimately correct - not just for regional spelling, but for any\n  blank where a learner could reasonably phrase the right answer more than one way.\n- Don't use this to make genuinely different answers \"equivalent\" - only phrasings of the\n  *same* correct answer.\n\n## Write stems and labels that stand on their own\n\nSomeone using a screen reader hears card text and question stems read aloud, often without\nthe surrounding visual layout for context. Every question, card front, clue, and label\nneeds to make sense read in isolation:\n\n- Don't write a stem that depends on seeing an image, color, or spatial position (\"the one\n  on the left,\" \"the green option\") - none of these content types in practice rely on\n  images for the correct answer, but avoid introducing that dependency in wording even\n  incidentally.\n- Keep sentences direct. A screen reader user re-parsing a long, clause-heavy stem to find\n  the actual question is a real tax that sighted skimming doesn't impose.\n- Spell out what an abbreviation means on first use if the activity itself is what\n  introduces it - don't assume context the learner doesn't have yet.\n\n## Match reading level to who's actually using this\n\nA teacher building a quiz for their students needs the *students'* reading level reflected\nin the questions, not the teacher's. If the source content's audience is implied (a grade\nlevel, \"my beginners,\" a specific course), write at that level - simpler sentence structure\nand more common vocabulary isn't dumbing content down, it's removing a barrier that has\nnothing to do with whether someone understands the actual subject.\n\n## Be honest about what's outside Interactify's control\n\n**Interactive Video takes a YouTube URL as input - Interactify has no influence over\nwhether that source video has captions.** If accessibility of the video itself matters to\nthe person asking (and for an educational use case, it usually does), say so plainly rather\nthan implying the activity is fully accessible end-to-end: \"the questions and interactions\nI'm adding are accessible, but captions on the video itself depend on what's available on\nYouTube for this specific video - worth checking before using this with students who need\nthem.\"\n\n## What you don't need to worry about\n\nH5P.Crossword's own runtime already offers a non-grid input mode (Tab-navigable fields,\nstyled like Fill in the Blanks) for people who can't or don't want to use the visual grid -\nthis is a real, already-built feature of the library, not something that needs to be\ndesigned around. Likewise, keyboard operability and screen-reader labeling for every content\ntype here come from the vendored H5P runtime itself, not from anything in the content you\ngenerate - focus on the wording and answer-matching guidance above, since that's the part\nactually within reach.\n"
}