Test Copilot's BYOK Provider and Model Selector for Keyboard Accessibility

GitHub announced on July 14, 2026 that Copilot for JetBrains expanded bring-your-own-key capabilities. A proposed accessibility test plan outlines keyboard and screen-reader expectations for the provider and model selector, focusing on dependent workflow transitions. The plan emphasizes testing dynamic updates and state changes rather than static screenshots.

GitHub announced on July 14, 2026 that Copilot for JetBrains expanded bring-your-own-key capabilities. Primary source: GitHub Changelog, July 14, 2026 https://github.blog/changelog/2026-07-14-github-copilot-for-jetbrains-expands-byok-capabilities/ . Provider and model selection looks like two dropdowns, but behaves like one dependent workflow: php credential context - provider - compatible models - confirmed session This is a proposed accessibility test plan, not a hands-on review. It does not claim that the current product has an accessibility defect. A keyboard or screen-reader user should be able to reach the provider control, discover its name and current value, inspect options, commit or cancel, understand that model choices changed, and select a compatible model without losing context. Use this matrix: | Case | Action | Keyboard expectation | Screen-reader expectation | State expectation | |---|---|---|---|---| | P1 | Reach provider | Visible focus | Name, role, value | No change | | P2 | Open options | Documented key works | Expanded state is clear | Existing value retained | | P3 | Browse providers | No focus escape | Option and selection announced | Browsing does not commit | | P4 | Select provider | Pointer not required | New value announced once | Model refresh begins | | M1 | Reach model after refresh | Focus not stolen | Availability communicated | Options match provider | | M2 | Search models | Keys do not conflict | Query and result are clear | Search does not select | | R1 | Change provider later | No trap | Invalidated model explained | Stale pair cannot submit | | E1 | Loading fails | Retry/cancel reachable | Error and next action announced | Last valid state is clear | The matrix separates interaction, announcement, and state correctness. A control can pass one and fail another. ide: "<product and exact version " plugin: "GitHub Copilot <exact version " os: "<name and version " assistive technology: "<name and version " keymap: "<default or named alternative " initial state: "<unconfigured or existing selection " Vary one versus many providers, short versus long model names, loaded/loading/empty/error states, and changing provider before and after selecting a model. Dynamic updates deserve special attention. Automatically moving focus can disorient users; silent refresh leaves them unaware. A useful expected pattern is to keep focus stable, announce a concise change when needed, and let the user navigate deliberately. Record perceived behavior rather than prescribing an implementation API. Exact controls, shortcuts, supported assistive technologies, and provider behavior must be confirmed against current GitHub and JetBrains documentation. The durable lesson is to test the transition between dependent controls, not only two static screenshots.