Recommended scope decision: Review anonymous/public practice separately from Word Lab’s optional signed-in teacher, attendance, assignment, and student-portal features. Approval for one does not have to mean approval for all.
1. Product and instructional fit Define the approved audience and purpose. Identify grades, programs, instructional settings, and whether the Lab supplements—not replaces—core instruction. Review representative activities in each requested Lab. Confirm age-respectful design, accuracy, accessibility needs, and alignment with local scope/sequence. Document interpretation limits. Lab results are not standardized scores, diagnoses, eligibility decisions, IEP progress measures, or official records unless the district deliberately establishes an approved process. Identify staff training and supervision needs. Include session routines, support settings, read-aloud boundaries, and response to safety concerns raised by Life Lab topics.
2. Data and privacy Review the data-collection map and each Lab’s privacy notice. Verify browser-local data, analytics, optional server records, and technical hosting data. Choose the minimum-data configuration. Prefer anonymous public practice; specify whether names, initials, approved codes, rosters, notes, results, or attendance are allowed. Determine legal authority and consent requirements. District counsel/privacy staff should evaluate FERPA, COPPA, state student-privacy law, board policy, and notice/consent rules. Define retention, correction, export, and deletion procedures. Include shared browsers, educator account transitions, departed students, records requests, and end-of-year cleanup. Confirm no disallowed secondary use. Current notices describe no behavioral advertising or sale; formal reviewers may require contract language covering ads, profiling, model training, redisclosure, and commercial use. 3. Security and identity Review authentication and authorization for requested features. Confirm teacher sign-in, account ownership, teacher-record isolation, student code handling, family invitations, and sharing-link behavior. Request required security documentation. Districts may need hosting/subprocessor details, encryption statements, access-control practices, backup/recovery, vulnerability management, incident response, breach notice, and independent assurance reports. Review link and code exposure risks. Set rules for assignment links, student codes, screenshots, exports, printed reports, and classroom displays. Establish an incident contact and response path. Do not send student records through the public feedback form; define a secure escalation route before server-stored use.
4. Accessibility and equity Review the Accessibility Status & Self-Assessment Report . Note the WCAG 2.2 AA target and that formal conformance certification is not claimed. Test with the district’s actual devices and assistive technologies. Include keyboard, screen reader, magnification/reflow, speech input, switch access, touch, reduced motion, and required browser/OS combinations. Plan alternatives for non-equivalent content. Provide human reading, tactile graphics/manipulatives, AAC, sign-language interpretation, or alternate activities as required by student plans. Confirm access does not depend on public comparison or speed. Review motivation, retries, badges, and progress displays for learner dignity. 5. Legal and procurement Review the Terms of Use . Identify whether district terms, DPA, confidentiality, audit, insurance, indemnity, governing law, records, or service-level language is required. Confirm ownership and classroom-use permissions. Define what educators may copy, print, adapt, link to, or redistribute. Verify cost, renewal, and change-management expectations. The public sites are currently available without a student subscription; do not assume future pricing, features, or availability without written terms. Record the district decision and approved feature set. Include approver, date, review cycle, limitations, and whether server-stored Word Lab tools are included. 6. Pilot and rollout Run a small anonymous pilot first. Use the anonymous classroom guide and the device/classroom pilot . Collect accessibility and instructional feedback without student identifiers. Record barriers, error patterns, workload, and teacher/student experience. Resolve high-severity barriers before expansion. Document required remediation, workarounds, ownership, and deadlines. Schedule re-review. Revisit approval after major feature, privacy, accessibility, hosting, authentication, or terms changes. District decision record Reviewer(s): _________________________________________
Decision/date: _______________________________________
Approved sites/features: ______________________________
Restrictions or conditions: ____________________________
Next review date: ____________________________________
Checking a box is only a planning aid and is not evidence of legal compliance, security certification, accessibility conformance, or district approval.