I'm going to try to be thorough here, and tailor the following for something like Starfighter that's intended for hackers or aspiring hackers, but this probably won't be exhaustive.
What does work:
- Native apps that use the platform's standard controls
- Native apps that have custom controls but implement the platform's accessibility APIs (this is a lot of work)
- Web apps that use standard HTML elements in the intended ways (e.g. links, form fields, headings, lists, tables that actually represent tabular data...)
- Web apps that implement custom widgets (e.g. a div or span that's actually a button) and provide the appropriate ARIA (http://www.w3.org/WAI/intro/aria.php) properties and keyboard focus behavior
- Flash apps that implement the Flash accessibility API, or use standard Flash or Flex controls and are compiled with accessibility enabled. I really don't know much about this.
JavaScript as such is not a problem for any remotely recent screen reader or other access technology. Neither are dynamic page updates, a.k.a. Ajax or single-page apps. Though in some cases, it may be helpful to mark a dynamic area of a page as an ARIA live region so screen readers will read new content automatically; the textbook example is a chat app.
- Late addition (because it was so obvious to me I almost missed it): anything command-line or terminal-based (second late addition: as long as the user can use their own terminal emulator).
What's not ideal but still basically usable for a tech-savvy blind user (i.e. anyone who's actually going to play Starfighter):
- In web apps, links or buttons that are images with no text equivalent (e.g. alt or title attribute), but where the meaning can be deduced from the link or image URL; in some screen readers, users can even add their own labels for these
- In web apps, elements that are effectively buttons (i.e. they have a click event handler) but are just generic divs or the like rather than actual links or buttons, and don't have the appropriate ARIA role; a user can usually deduce from context that these are buttons in disguise, and use a screen reader command to click them
What isn't generally considered accessible, but can be used with some effort through a screen reader feature or plugin:
- Textual information that is presented as an image, where all the info the user needs is in the text itself (e.g. not in any actual graphics, highlight colors, or the like), and the user doesn't need to click within that part of the screen; in that case, the user can use OCR to get at the text
What isn't generally considered accessible, but could be spun as just another challenge for the aspiring blind hacker wanting to play Starfighter, to be overcome by writing scripts for their screen reader or something like the Greasemonkey add-on for Firefox:
- Pseudo-buttons (as above) that are HTML inline elements (e.g. spans) rather than block elements (e.g. divs). The screen reader will probably present these as a single block of text with no immediate way to click on individual pseudo-buttons, but a hacker can probably write a script to add the appropriate ARIA role to these elements or do something equivalent at the screen reader level.
- In web apps, information that is presented visually without using appropriate semantic markup or ARIA attributes, but where the visual state of the element can be deduced from something like its class or id attribute, or even the presence of specific CSS in the style attribute. An example would be a list view or grid widget where the currently selected item is highlighted; assuming the selected item has a distinctive class or style attribute, a hacker should be able to write a script to add the appropriate ARIA attributes or do something equivalent at the screen reader level.
- A scenario like the one above where text is presented as an image, but the user now has to click inside that part of the screen. If the location of each clickable area (e.g. button) in pixels is a constant, then a hacker should be able to define hotspots in their screen reader, possibly with a little sighted help.
- On Windows, native apps that implement a custom UI and don't implement the platform's accessibility APIs, but use GDI (the original, obsolescent Windows graphics API) to draw to the screen. Since the early 90s, WIndows screen readers have used some truly hideous hacks to cope with this rather common scenario (if interested, the best explanation I know of is in this rather FUD-y piece I co-wrote years ago: http://ur1.ca/n4eyk). Windows screen readers have heuristics for things like detecting highlighted text and working with custom edit controls by detecting the position of the caret. And people have written very elaborate (and fragile) screen reader scripts to make various niche Windows applications usable.
What really isn't feasible to work around, even with hacking:
- A scenario like the one above where text is presented as an image, but now the user has to know the foreground or background color of some of the text, e.g. to know which item in a list is selected. I'm not aware of any screen reader OCR feature or add-on that can provide that info.
- On platforms other than Windows, custom widgets that don't implement the platform's accessibility APIs basically boil down to the same thing as above. Ditto for a web app that implements its UI using canvas, WebGL, or the like.
- Late addition (another one that was too blindingly obvious to me): Graphics that have no text equivalent (e.g. alt or title attribute in a web app), and where the user doesn't have anything else to go on, like a link URL, image URL, or element ID.
I'm happy to discuss any of this in more depth, on or off HN (see my profile for slightly obfuscated contact info). I guess the question of what does and doesn't work is such a natural first question for any developer new to accessibility that lists like those above should really be published somewhere easy to find, albeit with less of an emphasis on scenarios that require workarounds by a user who's a hacker or aspiring hacker.