diff --git a/chartability.csv b/chartability.csv
new file mode 100644
index 0000000..f8672b6
--- /dev/null
+++ b/chartability.csv
@@ -0,0 +1,51 @@
+Test Name,Principle,Critical,Description,Good Examples,Tools or Testing Method,Knowledge Type,Resources,Limitations and Caveats,POUR Coding,Additional Category Coding,Test performed,Test failed,Audit notes,Related files
+No explanation for purpose or for how to read,Understandable,Yes,"Chart should explain its purpose and how to read, use, and interpret it.",,,research,https://doi.org/10.1109/TVCG.2019.2917689,"The criteria for 1.3.6 ""Identify Purpose,"" 3.3.2 ""Labels or Instructions,"" and 3.3.5 ""Help"" all fail to necessitate explaining how to read a complex data visualization. Even simple data visualizations can give people trouble interpreting or understanding.",understandable,informative,,,,
+"No title, summary, or caption",Understandable,Yes,"A title, summary, context, or caption must be provided.",,,research,https://doi.org/10.1109/TVCG.2015.2467732,"We use Borkin et al here. The criterion 2.4.6 ""Headings and Labels"" is interesting in that it doesn't require headings and labels to be present, but only requires them to be sufficiently descriptive IF present. This is a serious flaw in the current standards, which is why we look to research in this space. https://www.w3.org/WAI/WCAG21/Understanding/headings-and-labels.html",understandable,informative,,,,
+Low contrast,Perceivable,Yes,"Geometries and large text must have >3:1 contrast against background, Regular text must have >4.5:1.",https://observablehq.com/@frankelavsky/high-contrast-for-data-visualization-with-examples,https://webaim.org/resources/contrastchecker/,standards,https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html,"Low contrast is the most common failure (88% of audits we have performed fail this). It also has the potential to be one of the most inclusive design spaces for representing data, perhaps outside of text treatment, content, and narrative design. Myndex Research (APCA/SPCA work) has noted the limitations of the WCAG 2.0/2.1 Model (which is based off of IEC/4WD 61966-2-1). The WCAG 3.0 Standard is likely to be much better, but work is still ongoing and not likely to become standard until at least 2025 or later.",perceivable,"presentation, visual",,,,
+Content is only visual,Perceivable,Yes,"Information in the chart must be available without visuals (no screen reader/braille support). At a minimum test using JAWS + Chrome, NVDA + Firefox (on Windows), VoiceOver + Safari (on Mac), and VoiceOver + Safari (on iOS). These devices must be able to access all chart information. All annotations, “visually apparent” trends or features, and all major narrative elements must be exposed to screen readers. Videos, presentations, and animations must include synchronized audio descriptions.",https://youtu.be/w6ntxLG6MLQ,"https://support.apple.com/guide/voiceover/welcome/mac, https://www.nvaccess.org/, https://www.freedomscientific.com/products/software/jaws/,  https://support.google.com/accessibility/android/answer/6283677?hl=en",standards,https://www.w3.org/WAI/WCAG21/quickref/#text-alternatives,"The heart of this test is about non-visual access via text alternatives and generally, screen readers and braille readers (in the tools section of this test) are ""assistive technologies"" (AT) that can determine if this has been done accessibly. Broadly the considerations here in this test may need to expand beyond just using these AT devices someday, depending on whatever technologies are used by people.","perceivable, robust","alternative, presentation, AT",,,,
+Small text size,Perceivable,Yes,Text (any) must not be smaller than 9pt/12px in size. Ideally only minor text is rendered at 9pt (Eg. axis labels) while all other text is larger.,,,research,https://doi.org/10.1167/17.5.8,"Testing for font size is highly complex and difficult if it isn't stored in data/metadata or known by the designer/developer. This is a difficult metric to measure and more tooling is needed to help with this. In addition, WCAG 2.1 has no requirement for text size. Ongoing work for 3.0 (thanks to Myndex) is integrating contrast evaluation with ""size"" (roughly approximating perceptial angle), since plenty of research has shown that size affects discriminability. But as we mentioned in the contrast limitations, this work is ongoing and non-standard. For more community resources, see: [https://accessibility.psu.edu/fontsizehtml/](https://accessibility.psu.edu/fontsizehtml/)",perceivable,"presentation, visual",,,,
+Interaction modality only has one input type,Operable,Yes,"If chart is interactive with a mouse (or another input device) it must also be made interactive for use with a keyboard. Test navigating to chart with keyboard, using tab and arrow keys. Focusing should mirror hovering, selecting (enter or spacebar) should mirror clicks. The chart must also be tested with a touch device and screen reader, as these devices may have different experiences than a keyboard.",https://progressiveaccess.com/chemistry/,,standards,https://www.w3.org/WAI/WCAG21/Understanding/keyboard-no-exception.html,"The keyboard interface (not literal keyboards but the technology they use to interface with software) is the single, most important thing to build and ensure when creating interactive content. Screen reader operability should always be tested alongside keyboard-only testing. In addition, we also should consider touch interaction. But how do we think about touch interfaces? Touch input often follows what is called the ""pointer"" interface, coupling mouse and touch interactions together. But touch has a much larger hit area, causing significant accessibility issues on mobile devices. This is largely an unsolved problem.","operable, robust","alternative, inter-operable, AT",,,,
+No interaction cues or instructions,Operable,Yes,"If chart has any interactive capabilities at all, it must be explained somewhere for users to understand. All keyboard controls must also be explained as well.",https://sf.gov/resource/2021/covid-19-data-and-reports,,standards,https://www.w3.org/WAI/WCAG21/Understanding/labels-or-instructions.html,"We have had long battles (in professional experience) with designers on this point. ""Why do I need to provide instructions? If it is a good design, no instructions are needed!"" And that simply is an ableist assumption. Instructions must be provided for any and all interactivity, including instructions for different input devices: hovering with a mouse or navigating with a keyboard.","operable, understandable","transparent, informative",,,,
+User style change not respected,Flexible,Yes,Styling changed by the user must be respected. Chart must not interfere with or override styling changes made by the user (such as importing a custom style sheet for use in an HTML application or web site).,,,standards,,"See: 1.4.4, 1.4.8, 1.4.10, 1.4.12, 2.2.1, 2.2.2, 2.2.4, 2.3.3","perceivable, operable, robust","flexible, presentation, alternative, user-controlled, respectful, empowering",,,,
+No table,Compromising,Yes,"A table must be provided that contains a human-readable version of the data the chart is based on. This may be excluded if the chart title, summary, context, or annotations are sufficient at conveying all relevant information contained in the chart.",https://www.wgbh.org/foundation/ncam/guidelines/effective-practices-for-description-of-science-content-within-digital-talking-books,,research,https://www.wgbh.org/foundation/ncam/guidelines/effective-practices-for-description-of-science-content-within-digital-talking-books,"Supplying a table is supported by empirical research via the Diagram Center/NCAM but has also largely been adopted by attempts by the community wishing to bypass Section 508 difficulties making a chart or graph accessible. Tables are often used to fully replace charts, argued as if they are equivalent experiences. Chartability does not take this design position (having a table doesn't mean everything else about a chart can pass). I've discussed in the past that tables are not enough, especially from an interactivity and navigation perspective because chart structures can represent relationships that are non-tabular. See: ""Information cannot be navigated according to narrative or structure."" The Design System for the US Government states that while a table might provide equivalent access to the data, ""a data table does not provide an equivalent narrative to a visualization,"" which is an important distinction. See: https://designsystem.digital.gov/components/data-visualizations/","understandable, operable, robust","alternative, transparent, presentation",,,,
+Data density is inappropriate,Assistive,Yes,"Data must be presented at an appropriate density. If too many elements are competing for the same space (approximate limit is based on cognitive load): clustering or patterns (or lack of) must be explained, chart must be aggregated to a higher level with less elements, or chart must be divided into smaller charts with less data. Visual density should serve a purpose, such as retaining the data's signal (when appropriate).",https://stackoverflow.blog/2022/03/03/stop-aggregating-away-the-signal-in-your-data/,,research,https://vita.had.co.nz/papers/bigvis.pdf,"Data density and comprehension might have studies? However, we couldn't find any research on this from a cognitive or perceptual perspective. Is that because this is such an ""obvious"" thing that nobody feels the need to question it? It is possible our lit review missed where these papers live.","perceivable, understandable","spatial, simplifying, excessive, cognitive load",,,,
+Controls override AT controls,Operable,Yes,Custom keyboard and touch controls must not override screen reader settings. Any custom key controls must only apply when the chart or elements have focus (no page or app overrides).,https://sf.gov/resource/2021/covid-19-data-and-reports,,standards,https://www.w3.org/TR/WCAG21/#character-key-shortcuts,"Not only are ""keyboard traps"" one of the worst experiences for keyboard and screen reader users, but key control overrides (such as overriding the native functionality of the tab key) can cause users significant issues.","operable, robust",respectful,,,,
+Navigation and interaction is tedious,Assistive,Yes,"Large blocks of repeated content must be skippable and interactions where the user is required to perform significant labor must not be considered essential (in content or function). The number of interactions or time required to perform a single task should be measured and compared across modalities (mouse pointer versus sequential keyboard versus search versus voice, etc).",,,standards,https://www.w3.org/WAI/WCAG21/Understanding/bypass-blocks,"Generally, the number of interactions or time required to complete a task is a usability measurement. But when different assistive technologies and inclusive design patterns are considered, this becomes an accessibility measurement as well. There should not be an access gap for someone's time investment in a data experience solely based on interaction and navigation means. There are significant cognitive accessibility overlaps as working memory and cognitive load increases throughout long and tedious interaction patterns.","operable, understandable, robust","assistive, time-consuming, empowering",,,,
+Reading level inappropriate,Understandable,Yes,All text (and alternative text) provided must target a reading grade level of 9 or lower. Tools may be used to automate reading level estimation.,,https://hemingwayapp.com/,standards,https://www.w3.org/TR/UNDERSTANDING-WCAG20/meaning-supplements.html,"Special circumstances may require complex terminology, but these should be explained using a reading grade level of 9 or lower.",understandable,"informative, simplified, plain",,,,
+Visual presents seizure risk,Perceivable,Yes,Chart must not pose a seizure risk when static or active. Chart must avoid red flashes and should avoid animating with red or have a significant portion of the display area use the color red. Tools like PEAT may be used to assess risk.,,https://trace.umd.edu/photosensitive-epilepsy-analysis-tool-peat-user-guide/,standards,https://www.w3.org/TR/UNDERSTANDING-WCAG20/seizure.html,We also acknowledge the work of South et al in their IEEE VIS poster where they used interaction techniques already built into three interactive visualizations to produce sequences capable of inducing seizures. We believe that the complex nature of interactive data experiences could merit more methodological attention for evaluating seizure risk.,perceivable,neurological,,,,
+Interactive context is not clear,Understandable,No,"If chart can affect the logic or layout of the page or if receives data or parameters from other UI controls or logic, this must be clearly communicated in text. Alerts or notifications must be provided that can be monitored programmatically without requiring navigation (to notify screen reader users, for example).",,,standards,https://www.w3.org/WAI/WCAG21/Understanding/status-messages.html,"Interactive charts often affect different areas of a page or view and different areas of a page or view can often affect charts. This relationship should always be clear to the user, as well as changes to state caused by the chart or its context. This uses criteria 4.1.3, 3.3.5, and 3.3.2.","understandable, operable","informative, transparent",,,,
+Information complexity is inappropriate,Understandable,No,"Information complexity must be appropriate to the task or goal of the visual. Often, this is an issue when charts have too many different kinds of information encoded (note that this isn't the same as density). Chart must not have more than one Y or X axis without first presenting two chart separately. Chart must not encode along a third spatial dimension (z axis) unless the data itself is 3D (spatial, modeling, etc). Chart should not contain more than 5 data categories.",,,research,https://nces.ed.gov/FCSM/pdf/2003FCSM_BlessingBradsher.pdf,"Note that 5 Categories comes from meta-study on effective working memory (See Table 9: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4591021/). Dual axis graphs in particular have been a contentious topic in visualization. We have encountered arguments in favor of using them when your audience are ""trained experts."" However, we are not sure how someone can evaluate their own audience's level of skill in a way that also ensures accessibility. We are also unsure of the benefits afforded this small group. But in any case, the point here is to exercise significant caution and to know that using dual axis graphs is inaccessible to a broad audience (and likely even expert audiences) as it is primarily an attentive, not pre-attentive, chart design.",understandable,"excessive, cognitive load",,,,
+Changes are not easy to follow,Understandable,No,"Chart changes must be easy to follow. If a chart’s data change is meaningful, it must employ animations for object constancy (no faster than 250ms or longer than 2s). Changes to state must be announced to screen reader users.",,,research,https://doi.org/10.1007/978-1-4842-1928-7_2,"Object constancy, as Bostock refers to it, is likely understudied in visualization research and certainly hasn't been interrogated from an accessibility perspective. Much more work needs to be done here. We synthesized three different sources to get our range between 250ms and 2seconds: WCAG guidance says a [limit of 5 seconds for animations without controls](https://www.w3.org/WAI/WCAG21/Understanding/pause-stop-hide.html#intent), we found that 2 seconds was a more appropriate limit in our own industry user studies for the domain of visualization, and [250ms minimal limit](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4591021/) is from a meta-study on visual fixation duration in older adults.","understandable, operable","transparent, cognitive load",,,,
+Metrics and variables are undefined,Understandable,No,"Metrics or variables must not be misleading or undefined. Chart must not lie and data (and source) must be defined. Metadata, metrics, calculations, and variables must be defined.",https://www.wgbh.org/foundation/ncam/guidelines/effective-practices-for-description-of-science-content-within-digital-talking-books,,research,"NCAM, Diagram Center","This seems straightforward enough on the surface: define the variables you are using. Often larger articles will explain variables or metrics in the body text of nearby paragraphs, but it is important to bring this information as close to a chart or data interface as possible so that someone can have the information ready and convenient.",understandable,"informative, transparent",,,,
+Statistical uncertainty isn't clearly communicated,Understandable,No,"Statistical confidence/uncertainty must be clearly and unambiguously communicated. If any statistical confidence interval exists, it must use clear conventions and provide textual explanation.",https://doi.org/10.1145/3173574.3173718,,research,https://doi.org/10.1145/3173574.3173718,"Hullman and Padilla are arguably both the giants of research in this space. Both of them have many papers in this space worth exploring for techniques and findings. The biggest limiation worth noting is that due to the complexity of this space, there may be contexts where it isn't entirely clear how to best communicate uncertainty (both from a cognitive accessibility standpoint and ethically).",understandable,"informative, transparent",,,,
+Axis labels are unclear or missing,Understandable,No,"Axis labels should be present and clear. Axis must not be truncated without a clear label. In rare cases axes may be removed (if adequate text explanation or annotation is provided). Otherwise, axis should be present and clearly labeled. Axis labels may be abbreviated but with a clear and consistent convention.",,,community practices,https://www.yellowfinbi.com/best-practice-guide/charts-visualizations/chart-axis-best-practices,"We really could use some robust research into axis labelling and design. Not only are there plenty of annoying engineering concerns in this space, but the low-level nature of effective axis design makes it a somewhat tricky problem. The high-level concerns for axis design (not being misleading, when truncation is appropriate, etc) are also relatively understudied from a research perspective. I think that this particular test could easily become a set of standards in our field.","understandable, perceivable","informative, transparent",,,,
+Controls are inappropriate,Understandable,No,"All controls provided must not be irrelevant to the message, question, or task of the chart. Chart's interactive scope and functionality must not be too broad. The chart should if it can have irrelevant functionality removed.",,,community practices,https://inclusivedesignprinciples.org/#add-value,"This one is actually quite hard to find good example articles for because it seems so obvious. Clearly, one might think, we should not have controls and functionality that are effectively useless or excessively taxing to use. Every component, module, widget, and control we provide should add value. Despite this seeminly apparent requirement, in the our past auditing and industry work we have found that many cognitive barriers exist when interactive data visualization tools and applications have more controls than are necessary for the task. This seems like an easy paper or blog waiting to be written! (See: any dashboard in Tableau. They are all able to drag-select, click, and hover even when those interactive features provide virtually no value to the user. Tableau, especially has a problematic interaction-by-default approach.)","understandable, operable","excessive, cognitive load",,,,
+Does not conform to standards,Robust,No,"The chart must conform to appropriate compliance standards. The chart must pass all relevant WCAG 2.1, Section 508, or equivalent requirements where applicable. (This is intended as an automatic failure until the chart can be fully evaluated.)",,,standards,https://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-parses.html,Chartability is not intended to compete against or completely replace any existing standards and guidelines but work alongside them.,robust,inter-operable,,,,
+Semantically invalid,Robust,No,"Semantically invalid use of document elements (if it functions like a button, but it is semantically other than a button, etc). Chart must be semantically valid according to modern standards. Initial testing (on the web) may be automated using any combination of: Axe-core, Wave, HTML Codesniffer, Accessibility Insights, or W3C Markup Validation but may only pass once a screen reader test has also verified the experience (see: Perceivable Failures for screen reader info).",,https://www.deque.com/axe/devtools/,standards,https://www.w3.org/WAI/WCAG21/Understanding/name-role-value.html,,robust,inter-operable,,,,
+Fragile technology support,Robust,No,"Chart access must not be isolated to one browser, device, software, or operating system. There must be a diversity of technological means to access the chart and its information and functionality.",,,standards,https://www.w3.org/WAI/WCAG21/Understanding/concurrent-input-mechanisms.html,,robust,"inter-operable, AT",,,,
+Color is used alone to communicate meaning,Perceivable,No,"Color must not be the only channel for conveying meaningful or essential information. For categorical color schemes: Textures, shapes, or size (for filled elements) or dash patterns (for lines and paths) are required.",https://observablehq.com/@frankelavsky/no-use-of-color-alone-in-data-visualization,,standards,https://www.w3.org/WAI/WCAG21/Understanding/use-of-color.html,"While this standard is very difficult for the field of data visualization to wrestle with, there is also little research that explores effective strategies. We need more work in this space, especially for color schemes that scale based on numerical data (sequential, ordinal, etc). See: https://observablehq.com/@frankelavsky/experimental-color-scale-textures",perceivable,"alternative, presentation",,,,
+Meaningful elements can be distinguished from each other,Perceivable,No,Primary chart elements must not be obscured by other elements (only a failure if discriminability or separability is required to understand the chart). Adjacent elements must have at least 1px white space between them (like stacked bars or pie charts where elements “touch”). Text (any) must not be obscured or overlapped by any other elements.,https://observablehq.com/@frankelavsky/contrast-and-no-use-of-color-alone-in-scatterplots#getting-a-better-look,,standards,https://www.w3.org/WAI/WCAG21/Understanding/distinguishable,"Distinguishability is the higher level principle (above contrast) and helps guide how contrast is calculated. But it also is generally concerned with how we ""perceive one thing from another,"" which is why this is separate from contrast. The gestalt techniques here especially have a very different approach than with contrast.","perceivable, understandable",presentation,,,,
+Not CVD-friendly,Perceivable,No,Color choice should be “colorblind safe” (distinguishable to people with color vision deficiencies). Use tools like Viz Palette or Chroma to test the chart's color palette. Must not have major warnings on either.,https://blog.datawrapper.de/colorblindness-part1/,"https://projects.susielu.com/viz-palette, https://vis4.net/palettes",research,https://doi.org/10.1007/s10209-021-00816-0,"Obviously we would imagine that standards require color vision deficiency consideration and this is actually where ""no use of color alone"" comes from. However, while it is assumed that having both high contrast and textures can resolve all CVD issues, it is still important to test color schemes against CVD simulations. So this heuristic is considered based on research, which we use Martínez et al's heuristics research for CVD in charts here.",perceivable,presentation,,,,
+Spacing is inappropriate,Perceivable,No,"Use of white space and other forms of padded, structured spacing should be appropriate. Too much or too little white space on charts with intervals (like a bar chart with thin bars and large gaps or vice a versa) can cause perceivable and understandable issues.",https://towardsdatascience.com/data-visualisation-principles-part-1-white-space-text-and-colour-13f520f90ce9,,community practices,https://www.calliaweb.co.uk/whitespace-not-just-a-waste-of-space,"While Headings and Labels are standards (2.4.6 and 2.4.10) for spacing and hierarchy reasons, ""white space"" specifically is a lower-level consideration that is massively important in effective, accessible data visualization. There is a research gap in this space. Another community article: https://medium.com/nightingale/how-to-use-whitespace-the-punctuation-between-visual-elements-5ff449709759","perceivable, understandable","presentation, convention",,,,
+Low contrast on interactive elements,Operable,No,"When interactive elements use color to communicate a change of state (like changing opacity, saturation, or hue on hover, focus, or selection), the new state should have at least 3:1 contrast against its previous state. Use WebAIM Contrast Tool or dropper tool. However, contrast color difference is not required if additional indications are provided, such as stroke thickness change (of at least 2px difference), a dash pattern is used, a marker is added, or other high-contrast technique. Ideally, both color and non-color strategies are used together (redundantly).",https://github.com/visa/visa-chart-components/tree/main/packages/utils#interactivity,,standards,https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html,"State change for interactivity is important to communicte clearly, arguably imperative for something to be operable. This is a good example of a strong intersection between Perceivable and Operable principles. We put this heuristic into operability primarily because while it is related to perceivability, it determines operability.","perceivable, operable",presentation,,,,
+"Keyboard focus indicator missing, obscured, or low contrast",Operable,No,"Visual keyboard focus indication must be present and easy to see. Focus indicator must have 4.5:1 contrast against background, must not be fully obscured, and must have at least a 2px border. Use WebAIM Contrast Tool or dropper tool.",https://github.com/visa/visa-chart-components/tree/main/packages/utils#interactivity,,standards,https://www.w3.org/WAI/WCAG22/Understanding/focus-appearance-minimum.html,"Focus indication is one of the most important and also least-designed parts of accessible visualizations. In all of our review, we only found custom, author-provided focus indication in Visa Chart Components and with some Apple charts, when leveraging their accessibility tree. All other keyboard-navigable charts appear to use default styles and assumptions (about enclosure, size, color, etc).","perceivable, operable",presentation,,,,
+Inappropriate tab stops,Operable,No,"Interactive elements (that represent buttons, links, or selectable features) must have a tab stop, while non-interactive elements must not have a tab stop. Every interactive chart element must NOT have its own tab stop unless the chart is small or the tabs are programmatically revealed (such as having a single tab stop at the root of a chart and then a way to enter further layers or sections of the chart using keyboard controls). At least one tab stop should be provided if a data table succeeds the chart and is interactive, otherwise a table should not have a tab stop.",https://observablehq.com/@frankelavsky/chart-component-boilerplate,,standards,https://www.w3.org/WAI/WCAG21/Understanding/focus-order.html,"This failure is very common for chart design on the web. Often, tabindex will be given to every single element in a chart, even if those elements aren't interactive. This is bad! I believe this practice stems from difficulty making SVG-driven charts accessible to screen readers and keyboard users alike. Note that progressively disclosing layers of tabindexed elements is a good strategy, care should still be taken to avoid placing too much tedium on the user in cases where the chart's childmost layer is dense (see ""Navigation is tedious"" in Assistive.","operable, understandable, time-consuming","convention, excessive, time-consuming",,,,
+Complex actions have no alternatives,Operable,No,"Special actions (brushing/zooming/filtering/gesturing) that use custom or complex chart controls must have a standard UI alternative available. These controls must be clear and easy to use with a keyboard, screen reader, and touch device.",,,standards,https://www.w3.org/WAI/WCAG21/Understanding/multiple-ways.html,"Both standards for 2.4.5 ""Multiple Ways,"" 2.5.4 ""Motion Actuation,"" and 2.5.1 ""Pointer Gestures"" all engage this issue. All special actions must have alternatives. Good design even considers alternatives that are not 1 to 1 translations. A 1 to 1 translation might be making a chart keyboard navigable and interactive to match a mouse hover/click. Alternative design for ""multiple ways"" might be also to provide a search function across the data or chart space in order to directly select elements.","operable, robust",alternative,,,,
+Long animations cannot be controlled,Flexible,No,"Longer, video-style or explanatory animations must have pause, stop, and start controls. Specifically, animations lasting more than 2 seconds or any looping animations must be able to be paused or stopped. Animations used to communicate transitions in the state of the data that last more than 2 seconds must provide a way for the user to start over.",,,standards,https://inclusivedesignprinciples.org/#give-control,"See: 2.2.1, 2.2.2, 2.2.4, 2.3.3","operable, robust","flexible, operation, alternative, user-controlled, respectful, empowering",,,,
+Scrolling experiences cannot be altered,Flexible,No,"Scrolling experiences must provide a way to be adjusted or opted out of. Infinite scrolling, parallax scrolling, and “scrollytelling” experiences must come with the ability to be turned off or used optionally, with an option like “load more” or “next” in its place for keyboard only users.",,,standards,https://inclusivedesignprinciples.org/#give-control,"See: 2.2.1, 2.2.2, 2.2.4, 2.3.3","operable, robust","flexible, operation, alternative, user-controlled, respectful, empowering",,,,
+Zoom and reflow are not supported,Flexible,No,"Chart space must be able to be zoomed using assistive technology or equivalent. Text, geometries, and all elements must change size appropriate to the type of zoom used. When zooming, content should reflow and not be cut off from view in two directions. Responsive design may need to consider re-arranging the display to ensure that no meaningful information or functionality is lost during reflow.",,,standards,https://www.w3.org/WAI/WCAG21/Understanding/reflow.html,"See: 1.4.4, 1.4.10, 1.4.12","perceivable, operable, robust","flexible, operation, presentation, alternative, user-controlled, respectful, empowering",,,,
+User's text adjustments are not respected,Flexible,No,"Text spacing and font-size changed by the user must be respected. Chart must not interfere with programmatic changes to font sizes or text spacing, such as importing a custom style sheet or using a browser’s build in zoom function. Font size and spacing must adjust accordingly.",,,standards,https://www.w3.org/WAI/WCAG21/Understanding/resize-text.html,"See: 1.4.4, 1.4.12","perceivable, robust","flexible, presentation, alternative, user-controlled, respectful, empowering",,,,
+Design is not consistent and familiar,Flexible,No,"Design must be consistent and familiar by default. Charts must be made consistent with one another across an application or environment, including sharing default styling and settings as well as those set by the user. Interaction defaults (such as keybindings or interaction patterns) should carry over between charts that perform the same task or funciton.",,,standards,https://www.w3.org/WAI/WCAG21/Understanding/consistent-identification.html,,"perceivable, understandable, robust","flexible, consistent, presentation, user-controlled, respectful, empoweringflexible, user-controlled, respectful, empowering",,,,
+Contrast and textures cannot be adjusted,Flexible,No,Contrast or textures must provide a way to be adjusted as-needed. Chart must not interfere with or override user’s independent contrast adjustments and chart must adjust accordingly to new settings. Chart textures (such as those used on fills) must be able to be turned on or off according to user preference.,,,community practices,https://observablehq.com/@frankelavsky/experimental-color-scale-textures,"In experiences with audiences in the past, we have found that if some chart textures are on by default, we are creating accessibility barriers due to their visual complexity (we lose or complicate pre-attentive features as well). So we argue that textures (whether on by default or not) must be able to be toggled according to user preference. Much more work and research needs to be done in this space, especially as it challenges the idea that a single design can satisfy everyone's access needs.","perceivable, robust","flexible, presentation, alternative, user-controlled, respectful, empowering",,,,
+Information can only be reached through single process,Compromising,No,"There must be more than one process available to reach the same information. If chart is contained within or participates in complex user interface flows, such as transitions between views or states, interacting with filters, or moving between pages, there must be alternative paths to reach that same state (such as with search features, parallel UI controls, etc).",,,standards,https://www.w3.org/WAI/WCAG21/Understanding/multiple-ways.html,"We have found that many analytical dashboards and applications suffer from their greatest strength, which is the ability to perform deep and complex analysis. These deeply exploratory experiences must have multiple ways to produce the same information. Ultimately, this is an information architecture problem. We recommend reading ""Your Information Architecture is an Accessibility Problem"" by Sarah Barrett: https://medium.com/known-item/your-information-architecture-is-an-accessibility-problem-cd54ae917f8e","perceivable, operable, understandable","alternative, tolerant",,,,
+Location and history is unclear,Compromising,No,"Current location in a system is not easy to understand. Similar to “more than one process” and “easy to share and reproduce,” current view and state of visualization (in a complex environment like a dashboard or app) must provide the user with breadcrumbs to guide their path as well as the ability to save, reload, and navigate history.",,,standards,https://www.w3.org/WAI/WCAG21/Understanding/location.html,"Breadcrumbs, history, and the ability to save and load all participate in systems that are robust, forgivable, error-tolerant, and kind to the user. Coincidentally, they are also all more accessible for cognitive reasons, especially when these features are communicated.","understandable, operable, robust","tolerant, transparent, empowering",,,,
+Interactions are not forgivable,Compromising,No,"Interactions and operations must be forgivable. When the visualization is interactive or has the ability to perform a task, the user must be able to both undo or redo their actions.",,,research,https://doi.org/10.1080/00140139408964958,"Error tolerance, error-tolerant design, and ideas like Norman's ""To Err is Human"" are relatively old and well studied. This finds its way into standards, but is unfortunately limited in scope. Interaction errors in data experiences can be quite complex. The criteria for 3.3.6 ""Error Prevention (All)"" technically only applies to data entry and text fields.","understandable, operable, robust","tolerant, empowering",,,,
+Information cannot be navigated according to narrative or structure,Compromising,No,"Chart must provide a way to be navigated according to its data or narrative structure. The title, description, annotations, and then lower level data structures should be navigable and in that order. Chart data that contains sub-grouping (like a stacked bar chart) or nesting (like a treemap or hierarchy) must provide keyboard navigation that can navigate between levels and/or laterally across levels (in a non-linear fashion). Keyboard navigation must be comparable to the data structure (including cases where the data structure is novel) as well as provide linear or tabular navigation (like in a table or list).",https://progressiveaccess.com/chemistry/,,research,https://dl.acm.org/doi/abs/10.1145/2745555.2746667,"We use Sorge et al as well as his later work with Godfrey here: https://link.springer.com/chapter/10.1007/978-3-319-94277-3_92. The criteria for 2.4.3 ""Focus Order,"" 2.4.5 ""Multiple ways,"" and 1.3.1 ""Info and Relationship"" get very close, but don't quite satisfy this. Early community attempts to engage this problem are Leonie Watson's ""Accessible SVG Line Graphs"" and Doug Schepers' work.","perceivable, operable, understandable, robust","alternative, transparent",,,,
+Table/data is static,Compromising,No,"Provided table must at least be downloadable, filterable, or sortable.",,,community practices,https://inclusive-components.design/data-tables/,"This particular community recommendation actually comes from the our experience working with people with disabilities who are also data experts. In many cases, having a table that is downloadable as a CSV satisfies many concerns since programs like Excel actually handle a lot of needs. A CSV is a low-level, flexible material compared to a chart, meaning that it has more potential to be molded by the user into the experience that suits their needs. Despite this, it is preferable to make tables that are rendered filterable (ideally with a search feature) and sortable.","understandable, operable, robust","inter-operable, alternative, transparent, empowering",,,,
+State is not easy to share and reproduce,Compromising,No,"Chart state must be easy to share and reproduce. If an analysis or complex interaction can produce a customized view, this view must be easy to share (such as with a single link, file, or saved state).",https://moz.com/blog/everything-you-never-wanted-to-know-about-google-maps-parameters,,community practices,https://key2consulting.com/share-power-bi-reports/,"Believe it or not, many complex dashboards and applications with a branching narrative or exploratory style of data interaction have no easy way to share their current state. In professional work in the past, we have found that this is a significant access barrier when an analyst digs deep into their analysis, discovers something worth sharing, and then has no easy way of sharing it. The resulting access barrier is often placed on others. It is both significant cognitive effort as well as a usability problem. Often, an analyst has to result to using a screenshot, but then the labor and ""proof in the system"" of the analysis is lost! In addition, screenshots are their own accessibility risk (as they must now be made accessible). We challenge engineers to consider how incredible google maps is at maintaining a user's exact parameters in a url so that if they share a link, whoever views it sees the same thing they do. The same cognitive-labor accessibility applies to other complex data interaction spaces.","understandable, operable, robust","alternative, transparent, empowering",,,,
+Visually apparent features and relationships are not described,Assistive,No,"Trends, clusters, patterns, outliers, or significant statistical semantics and findings that are considered “visually apparent” must be described through text at a minimum. Optionally, these features may also be exposed using sonification or tactile means or through other multi-sensory approaches.",https://www.highcharts.com/docs/accessibility/sonification,,standards,https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships,"This heuristic is actually a significantly unsolved problem when it comes to the building materials we have available to us. Not only are sonifications or tactile experiences often authored in parallel (but separate) from visualizations (and tend to be a 1 to 1 representation), but we lack the semantic tools to describe relationships between parts (such as outliers, comparisons, trends, etc). Many efforts have attempted to automate textual descriptions, but as Lundgard et al point out, this may not be possible at a meaningful level we require in order to understand higher levels of information (see: ""Accessible Visualization via Natural Language Descriptions""). This issue is related to 1.3.3 ""Sensory Characteristics,"" but also 1.3.1 ""Info and Relationships,"" which Brennan Young engages in a conversation on ARIA's github: https://github.com/w3c/aria/issues/991#issuecomment-668493619","perceivable, understandable","sonified, multi-modal, sensory substitution, automatic, fluid, intelligent",,,,
+Data in text is not human-readable,Assistive,No,"Data must be formatted to be human-readable. All textual information displayed (in data labels, annotations, axes, tables, legends, etc) must be formatted to an understandable level of content (ie “human readable”). These formats must also be made into versions that can be read and parsed comfortably by screen readers. (For example: 6500000000 should be formatted to 6.5b visually and to “six point five billion” when used in screen reader labels and alt text.)",,,standards,https://www.w3.org/WAI/WCAG21/Understanding/unusual-words.html,It is strange that axis labels (especially) have not had an intelligent solution built yet that can parse all the possible states of axis-related data and turn them into something usable and well-formatted for human reading. This could even have implications for well-written alt-text. We believe that this could be a low-hanging fruit for researchers or builders to explore who are looking to make a tool or library that is helpful for many others.,"perceivable, understandable","simplified, automatic, procedural",,,,
+Space does not handle extremes,Assistive,No,"Use of space should appropriately handle extreme difference or similarity in the data. Both extreme quantitative differences and similarities can produce unreadable charts. If chart elements are squished into margins due to outliers or together by too much similarity, this fails. Chart must automatically handle these issues or else it must be made clear to the user through annotations what is happening. If data is dynamic or producing automatic annotations is not possible, then chart must provide a way for the user to sort, divide, or filter the chart space on their own.",https://towardsdatascience.com/data-visualisation-principles-part-1-white-space-text-and-colour-13f520f90ce9,,community practices,,"Real data is often horrible. In analytical environments, especially those where a chart format is chosen and expected to display data that is the result of a user's interaction with parameters and filters, this problem becomes common. Charts must be adaptive and flexible to the extrema in the data (grow or change to fit new parameters) but also should recognize when parameters result in data that completes for the same space (mentioned in another heuristic). If two lines are so close together that it is almost impossible to see the difference between them, a new chart type might need to be chosen or some filtering should take place instead.","perceivable, understandable","spatial, automatic, intelligent, time-consuming",,,,
+"No default ""build-your-own"" provided",Assistive,No,"If the user is required to craft their own chart (say by combining variables in an analytic environment), a default, opinionated view of the data should be provided as a starting point.",,,community practices,,"This particular example comes from our experience working with people with disabilities in product and application testing contexts. ""Build your own"" analytical experiences are really difficult from a cognitive perspective, especially if this intersects with other access needs.","understandable, operable","default, automatic, assistive, time-consuming, empowering",,,,
+Target pointer interaction size is too small,Operable,No,"Interactive elements that can be targeted by a mouse or touch pointer interaction should have a minimum size of at least 24px x 24px. If elements are scaled according to data values (such as a scatterplot or otherwise), then alternative means must be provided to select, activate, or otherwise interact with the information or task that the element represents.",https://projects.fivethirtyeight.com/435-representatives/,,standards,https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html,"This is quite a hard requirement for accessibility in visualization because the spatial dimensions of visual marks are often mapped to variables. We argue that alternatives should be provided such as text labels that satisfy minimum size, accompanying data tables or search functions, alternative navigation and input (such as with a keyboard or non-precise touch input), or features like zooming or filtering. While we applaud efforts such as the use of voronoi diagrams on top of visualizations, we believe that these still pose significant operability barriers for people with motor impairments.","operable, perceivable",,,,,
+Difficult chart type has no alternative,Flexible,No,The user should be able to adjust the type or presentation of difficult or complex charts into more accessible alternatives that still accomplish the same analytical task.,http://cu-visualab.org/IDD/demo/,,research,https://dl.acm.org/doi/pdf/10.1145/3411764.3445743,"Pie charts, line charts without discrete marks, and bar charts without countable isotypes all pose cognitive difficultes. Chart types that are high risk for difficulty or misinterpretation should be presented alongside alternative charts or alternative explanations and charts should be available to help the user perform the same tasks. Optionally, users should be provided control over the presentation style of these chart types (eg change pies into treemaps or stacked bars, add discrete marks to line intervals, or add countable isotypes to divide bars).","perceivable, robust","flexible, presentation, understandable, alternative, user-controlled, respectful, empowering",,,,
\ No newline at end of file
diff --git a/package.json b/package.json
index 41c7cdb..05ae34d 100644
--- a/package.json
+++ b/package.json
@@ -1,9 +1,10 @@
 {
   "dependencies": {
+    "json-2-csv": "^5.5.9",
     "json2md": "^1.12.0",
     "showdown": "^2.0.3"
   },
   "scripts": {
-    "build": "node scripts/generate_markdown && node scripts/generate_html && node scripts/generate_docx"
+    "build": "node scripts/generate_markdown && node scripts/generate_html && node scripts/generate_docx && node scripts/generate_csv"
   }
 }
diff --git a/scripts/generate_csv.js b/scripts/generate_csv.js
new file mode 100644
index 0000000..eb8906e
--- /dev/null
+++ b/scripts/generate_csv.js
@@ -0,0 +1,81 @@
+const fs = require("fs");
+const path = require("path");
+const { json2csv } = require("json-2-csv");
+
+// Input and output file paths
+const inputFilePath = path.join(__dirname, "../includes/chartability.JSON");
+const outputFilePath = path.join(__dirname, "../chartability.csv");
+
+// CSV Injection Sanitizer
+function sanitizeForCSV(value) {
+  if (typeof value === "string" && /^[=+\-@]/.test(value)) {
+    return "'" + value;
+  }
+  return value;
+}
+
+// Read the JSON file
+fs.readFile(inputFilePath, "utf8", async (err, data) => {
+  if (err) {
+    console.error("Error reading JSON file:", err);
+    return;
+  }
+
+  try {
+    // Parse JSON data
+    const jsonData = JSON.parse(data);
+
+    // Add new columns with empty values to each object and sanitize all fields
+    const updatedData = jsonData.map((item) => {
+      // Sanitize all existing fields
+      const sanitizedItem = {};
+      for (const key in item) {
+        sanitizedItem[key] = sanitizeForCSV(item[key]);
+      }
+      // Add new columns (already empty, so no need to sanitize)
+      sanitizedItem["Test performed"] = "";
+      sanitizedItem["Test failed"] = "";
+      sanitizedItem["Audit notes"] = "";
+      sanitizedItem["Related files"] = "";
+      return sanitizedItem;
+    });
+
+    // CSV options to handle quotes and escaping
+    const options = {
+      quote: '"', // Use double quotes for fields
+      escape: '"', // Escape double quotes with another double quote
+      keys: [
+        "Test Name",
+        "Principle",
+        "Critical",
+        "Description",
+        "Good Examples",
+        "Tools or Testing Method",
+        "Knowledge Type",
+        "Resources",
+        "Limitations and Caveats",
+        "POUR Coding",
+        "Additional Category Coding",
+        "Test performed",
+        "Test failed",
+        "Audit notes",
+        "Related files",
+      ],
+    };
+
+    // Convert JSON to CSV with options
+    const csv = await json2csv(updatedData, options);
+
+    // Write CSV to file with BOM for Excel compatibility
+    const BOM = "\uFEFF";
+    fs.writeFile(outputFilePath, BOM + csv, "utf8", (err) => {
+      if (err) {
+        console.error("Error writing CSV file:", err);
+        return;
+      }
+      console.log("Chartability CSV file was saved!");
+    });
+  } catch (error) {
+    console.error("Error processing JSON to CSV:", error);
+  }
+});