Big thanks to @frankelavsky for doing the analysis and writing it up.

Perceivable issues:

• Many encodings across charts fail WCAG's 3:1 contrast rule. Consider adding borders (or dual borders) to all marks to ensure they can be perceived as separate from other marks or changing your color schemes. Also consider other techniques or caveats to this rule. Chart types that rely on overlapping marks by necessity are exempt from this, but you should consider their operability (such as dots with error bars being two separate, navigable marks - they should only be one as they are meant to be perceived as one). In addition, the 3:1 contrast rule for marks should ensure that they are still perceivable against a white background (this includes gridlines!).
• Many charts rely on color alone to encode meaning. Do not rely on color alone, even if it is a vetted "colorblind safe" scheme. Users employing high contrast display software or color-altering displays may change the color of any scheme they view, which renders many colorblind safe schemes different than originally authored. Directly label whenever you can. If you lack room for labels, add shapes to marks (like in scatter plots with different categories as some of your examples show) or textures to marks when all the marks must be the same shape (like a stacked bar chart).
• You should underline any links you provide so that color isn't the only channel to communicate the link.
• Your text treatment is generally pretty good, as a note. However, direct labeling is preferred to the use of axes and legends whenever possible.

Operable Issues:

• Keyboard-only. These ones are pretty difficult and being honest all of the charts fail keyboard-only operability. This is especially true in the interactive examples section. For example, I was not able to get your brush example to move using keyboard input alone. Not all users employ a screen reader. This means that if your charts that are mouse-interactive, especially ones which can affect the logic or layout of your overall content, they must also expose access to the same features and functions for users who use only a keyboard. This operability issue is specifically related to users with motor impairments (temporary or permanent) who are unable to use a mouse. Keyboard access is important.
  • Two important areas for keyboard-only are:
    1. Navigability. Consider using tab-stops to help users quickly get through your page to the important regions. (But avoid having too many tab stops.) Also consider alternative navigation structures that do not rely solely on render-order. In charts with many marks, this can be tedious and not-very-helpful. Consider adding search features or higher-level summaries (as we already discussed).
    2. Interactivity. Consider adding ENTER, SPACEBAR, and ESC keys to your charts. Mirror hover/mouseover events when focus events are called, mouseout when blur is called, and mirror click events when users activate with ENTER or SPACEBAR. Consider ESC key to help users exit charts with many marks and immediately lead them to the end of the chart space (so they can skip it). Note that browser support will become tedious when you start walking this path! Edge/IE will have some tricky caveats and require polyfills.
• Assistive tech: Screen readers. I could not get your examples to work reliably when using NVDA or JAWS (on Windows) on any of these browsers: Firefox, Chrome, Edge, and IE (IE is still used by 9% of folks leveraging assistive technology and I couldn't even test it because your website itself throws an error and fails to load the page). The issues were primarily related to navigation, although there were some (minor) issues with your ARIA. I would actually consider your ARIA to be fairly good, despite navigability issues. Your examples worked well in Safari + VoiceOver and Chrome + VoiceOver. I did not test firefox, as I assume it is fine with VoiceOver as well (and this combo is a very small % of users anyway). All in all, I would say your screen reader support is reaching around 12-15% of users.
• Overall, your page has issues for screen reader and keyboard-only use (even with voiceover), especially when leveraging the "full page" view in the chart editor. You visually hide elements that are still keyboard navigable. Also, the code-editing section caused very strange navigation issues. It gives ARIA-driven instructions to press alt+f1, which is not exposed to mac users. Also, f1 is a reserved key in many screen readers. I would suggest a different key combination. As a note, I had to remove the code editor's HTML from the page in order to test the chart area when using NVDA and JAWS. (Note by @domoritz: filed as Showing a single vis is not accessible editor#663)
• Touch support and touch + screen reader. I did not test mobile, touch, or mobile screen readers.
• Navigating between the "RUN" button and the code/chart space is a bit tedious. Perhaps consider rearranging the space or adding an alternative/second RUN button that is later in the rendered order than the code editor?

Understandable Issues:

• Dataviz as a whole can be quite difficult here. For users with cognitive/mental issues, you may need to provide captions that mirror your auto-generated and manually-supplied ARIA summaries. Consider that users with attention, retention, and cognition impairments may have a hard time using your site. (As a whole though, I thought it was pretty good - but to do cognitive accessibility well the only road to take is bringing in actual users to test.)
• Overall, your ARIA is pretty good - but you may want to consider removing the key names (or allowing this to be specified or not). When we have tested with users, many prefer a terse label: "15. May 3" instead of "Value: 15. Date: May 3." But your key names all seem to be nice and human readable, so it is probably fine as-is.
• However, some of your ARIA (on lines without other marks, for example) are quite confusing. I am not sure what I am reading here. Your key names are not human-readable and you may be excluding some information from the data as well. In addition, your ARIA on some multi-mark charts exposes labels for dots separate from their error bars and also includes far more mathematical precision than necessary. These long and precise values are painful to read using assistive tech. Consider formatting your numbers to be easier for comparison (given the scope and range of your data's values).
• I would recommend more robust, higher-level ARIA-descriptions as well as accompanying captions (but as we discussed, this is no easy task to automate if you want it done well). For the sake of your examples at least, I would suggest manually supplying chart outcomes, findings, summaries, and statistically relevant insights gained visually. In your scatterplot, you simply describe it as a "A scatterplot showing horsepower and miles per gallons." At a bare minimum, I would include the grouping (region) in this descriptor as well. But as a more serious issue: a non-sighted or low-vision user with a screen reader is left out of the fact that there is a large cluster and general trend/shape to all the marks. They would have to navigate many, many points and do a lot of mental math in order to get the same information that sighted users do. (I would also argue that the massive overlap renders the differences in category non-accessible even to sighted users! Scatterplots are hard.)
• Consider adding a table to all of your charts. This can be shown/hidden via a button or simply rendered underneath. Many users prefer to navigate tables and wish instead to skip charts entirely. I highly recommend adding tab stops or using a link if you add a table. In the case of charts with large marks, it will take users many button presses to reach the end of the chart space and on to the table/table-button.

Robust Issues:

• In general, I would add: search, filtering, and dynamic manipulation features outside of the chart space that mirror your wonderful interactive features and also add robust, multi-modal controls. Trying to make these features keyboard-operable could be tedious. Instead consider a mirrored control space. Multiple channels for a user to achieve the same outcome is helpful for capturing different user preferences and needs. As one example: If your brush-filtering was operated with two text-based filter inputs for each cartesian dimension, then keyboard users could adjust the brush using only text input.
• Consider adding aria-live regions as well as toast notifications to pages where an interaction affects areas of the page that the user does or does not currently have focus. This is helpful for cognitive, motor, and vision impaired users. This is especially important if a user is capable of manipulating something late in their logical order of the page that has an affect on something they have already encountered (like brushing the last chart in this crossfilter example). Non-sighted users tend to navigate forward and expect interactions to affect later-order items from the location of their interactions.
• Changing the CSS of the page manually does not affect elements that use inline-styling. Some users with visual impairments employ custom style-sheets to pages. Consider using CSS classes whenever possible, as opposed to inline styling.