Information Visualization and Analytical Interaction Design Guidelines

For designers and engineers: a chart lets a person believe that "the difference I see is the difference in the data, and the action I take on the chart is an action taken on the data." These guidelines do not prescribe which chart type to pick or which color palette to pair — they specify the conditions that must hold for those two beliefs to be warranted: the encoding must be reversible back to the data, the basis of that data must be statable, an estimate must not pose as a certainty, the conditions currently imposed on the view must be visible and removable, the process that led to this point must be retained, and someone who cannot see color must still get the same facts.

Information visualization maps data into graphics; analytical interaction lets users filter, link, zoom, drill, and compare on top of that graphic. The design must simultaneously guarantee that magnitude expression is trustworthy, current conditions are explainable, analytical actions are recoverable, and the artifact remains understandable once it leaves the interface.

These guidelines consist of six principles and 42 rules. Each rule belongs to one principle, and its numbering corresponds to that assignment; together the rules cover encoding, data provenance, uncertainty, current conditions, the analytical process, and equivalent access. A static report selects the applicable clauses according to its actual capabilities; an interactive analytical product must also verify its loading, failure, recovery, and export processes.

Each rule is used to answer three questions: what design must decide, what facts engineering provides, and how the user knows the decision has taken effect. Statistical methods and domain-specific conventions are judged by the relevant specialists; these guidelines require that their declarations match the results and that unsupportable conclusions be made explicit. Chart libraries, brand themes, and technical architecture are chosen by the product.

Four chapters in all: Chapter 1 the principles, Chapter 2 how to read and look up the rules, Chapter 3 the rules in detail, Chapter 4 terminology; the verification checklist and evidentiary notes are in Appendices A and B, the complete sources are in reference.md, and the configurable items are in Information Visualization and Analytical Interaction Design Token.

---

1. The six principles¶

The six principles divide design responsibility by regulated object: each principle governs obligations on one category of object, and each rule belongs to exactly one principle according to the direct regulated object of its obligation. Different objects mean the principles do not substitute for one another — this is both the basis for the division and the way to test it.

A single scenario can touch several principles at once — an analyst brush-selects three months on a sales-trend chart colored by region, drills down to city level, sorts by year-over-year growth rate, and screenshots it into a group chat. This one step simultaneously faces whether the color channel is being reused for another meaning (VZ1-2), whether the aggregation method changed after drilling down and whether that was stated (VZ2-4), whether the algorithm and base period of the year-over-year figure are resolvable (VZ2-6, VZ4-5), whether the brush selection and sort order travel with the screenshot (VZ5-3), and whether a color-vision-deficient colleague in the group chat can distinguish those three lines (VZ6-1). This is not a classification error: the five rules constrain obligations on five different regulated objects — one is the meaning of a channel, one is the processing of data, one is the algorithm of a derived quantity, one is the conditions an artifact carries, and one is a perceptual path. Mutual exclusivity and exhaustiveness are a claim this division must pass, not a fact established by declaration: when a rule's addition, removal, or assignment is in doubt, verify it with the classification test in Appendix A. If the test fails, what gets changed is the division of the principles.

The two boundaries in this division that most need ongoing testing are stated here explicitly: VZ1 and VZ2 — VZ1 governs "what shape this magnitude has been drawn as," VZ2 governs "where this magnitude itself came from." A bar whose length is not proportional to its value belongs to VZ1; a number on a bar pieced together from three sources with different provenance and not stated belongs to VZ2. The same instance of "this looks wrong" can often be explained by either side; the assignment depends on whether the regulated object is the graphical property or the data processing. VZ4 and VZ5 — VZ4 governs whether the view conditions at this current moment are visible and removable, VZ5 governs whether the process from the starting point to this moment can be reviewed, rolled back, and taken away. "Can you currently see which regions were filtered out" is VZ4; "what was filtered in the previous step, can it be rolled back, and does the export still show it" is VZ5. If assignment disputes recur in practice at these two boundaries, the principles should be adjusted rather than adding an intermediate layer.

Principles are used to understand the rules and adjudicate assignment; they are not themselves standalone determination items. When interpretation of a principle conflicts with a specific clause, the applicable clause governs, and the ambiguity needing clarification is recorded.

A rule's assignment being unique does not mean its mechanism cannot be reused. A structured description of "the current view's conditions" is simultaneously the carrier for condition visibility (VZ4-1), the source of content for what an export carries (VZ5-3), and the basis for conditions being readable on an equivalent path (VZ6-5); a "field-provenance registry" simultaneously supports provenance being obtainable (VZ2-2), the annotation of provenance changes (VZ2-3), and the resolvability of a derived quantity's algorithm (VZ2-6). The same mechanism serving multiple purposes is normal; which rule it is written under depends on the direct regulated object of the obligation.

2. How to read the rules¶

2.1 The structure of each rule¶

In one sentence, summarizing the force of each part: the rule's main text states the requirement; Applies to and Boundary conditions together bound the scope of that requirement; Design application, Verification examples, Counterexamples, and Basis and references add no separate obligation.

A rule states the nature of a behavior, not the implementation: that the conditions currently imposed on a view must be visible and removable is product behavior; whether that is carried by a condition capsule, a sidebar list, or a line under the title is a design solution — the two must correspond, but they are not the same deliverable.

2.2 Normative terms¶

The main text of a rule uses three levels of normative term:

• MUST: not satisfying it means non-compliance with these guidelines. Without it, some promise made to the reader would fail in a foreseeable situation — this is the sole basis for marking something MUST.
• MUST NOT: the negative counterpart at the same strength as MUST, naming a behavior that must not occur; "MUST NOT" and "is forbidden" are equivalent in the main text.
• SHOULD: followed by default; when there is genuine reason to deviate, record the reason and the alternative, and accept the same verification. Deviation needs no approval, but it must leave a trace. "SHOULD NOT" is the negative counterpart of SHOULD.

Compliance determination takes the independent obligation clauses in the main text as its unit: a declarative sentence without a normative term carries the strength of the rule heading it belongs to; a clause with an explicit normative term is judged at its own strength — a MUST NOT/forbidden clause inside a SHOULD rule remains a hard constraint (VZ1-6, VZ1-7, VZ2-6, VZ3-5, VZ3-6, VZ4-6, and VZ5-5 contain such clauses), and the strength annotation on a rule heading or in the quick-reference table does not replace clause-level binding force. "Cannot" in the main text is used only for statements of capability or fact, and expresses no obligation.

Strength indicates binding force, not importance.

2.3 The two sides of a counterexample¶

Counterexamples come in two sides: "under-delivery" is missing this requirement; "over-delivery" is turning every chart into a piece of technical documentation longer than the chart itself in order to satisfy it. Both count as getting it wrong. This field is broken in dense ways at both ends: at one end, truncation, area inflation, and dual-axis alignment turn a small difference into a dramatic story; at the other end, out of fear of being wrong, every conclusion gets buried in disclaimers — a line chart accompanied by six lines of "data for reference only, provenance may be adjusted, does not constitute any recommendation," and the reader still has no idea how that line was calculated. Being careful is not the same as taking no position, and annotating is not the same as pushing the judgment onto the reader. Only a chart that can be read is a chart that can be called honest: piling on every interval, footnote, and warning at once leaves people unable to read the real conclusion, just as omitting them does.

2.4 Rule quick reference: 42 rules¶

The table below is the one-sentence memorable version of every rule; click a rule's name to jump to its complete text in Chapter 3. The quick reference does not substitute for each rule's applicability conditions and complete requirements; a few SHOULD rules contain forbidden- or MUST-level clauses (VZ1-6, VZ1-7, VZ2-6, VZ3-5, VZ3-6, VZ4-6, VZ5-5), and the main text governs the determination (see 2.2).

VZ1 Encoding is reversible

VZ2 Provenance is checkable

VZ3 Uncertainty is not omitted

VZ4 Analytical conditions are visible and removable

VZ5 The analytical process is traceable and portable

VZ6 Data is perceivable and reachable

2.5 From task to acceptance¶

Determine what judgment the reader must make first, then choose the encoding and interaction. Below is the order of application; it adds no mandatory clause.

Each item records "rule number / applicable scenario / design decision / source of operational fact / user feedback / verification result." Results fall into passed, failed, not applicable, or not tested; not applicable requires a reason, and not tested must not be counted as passed. A MUST-level failure cannot be offset by a high score on another item; a SHOULD-level deviation records the reason, the alternative, and the verification result.

3. Rules in detail¶

This chapter expands all 42 rules across the six principles. Each rule's structure and the binding force of each part are given in 2.1; the design applications, verification examples, and counterexamples within them are only notes that aid implementation — they do not prescribe a sole graphical form, nor do they require an additional standalone deliverable document.

3.1 VZ1 Encoding is reversible¶

The entire persuasive force of data visualization rests on one assumption: that a difference on the chart corresponds to a difference in the data. This principle governs the conditions that assumption needs to hold — what each visual channel corresponds to, whether it corresponds to only that one thing within this chart, whether the conversion from magnitude to shape has been inflated or compressed, and whether the chosen channel can support the reading task the reader is asked to perform. It constrains the mapping itself between graphical properties and data magnitude, not where the magnitude comes from (that is VZ2), and not whether the magnitude is accurate (that is VZ3).

VZ1-1The encoding mapping is resolvableMUST¶

In one sentence: Every visual channel carrying data can state which field it corresponds to, in what unit, and over what range.

Applies toany view that represents data using position, length, angle, area, color, size, shape, or another visual property.

Rulefor every visual channel in a view that carries data, its corresponding data field, dimension and unit, value range, and mapping method (linear, logarithmic, quantile, discrete binning, etc.) MUST be obtainable, and MUST match the actual rendering. The test for "obtainable" is whether the reader can reach it while looking at the chart, not whether it is written down in some document — axis labels, a legend, an explanatory area, or an expandable encoding description can all carry it, but it must not exist only outside the product. A visual property carrying decoration, branding, or grouping structure without encoding data MUST NOT be presented in a form that implies data meaning; the boundary values of bins, quantiles, or manual segmentation MUST be obtainable, not given only as color blocks without an interval.

Boundary conditionsthis rule does not require every chart to permanently display a complete encoding description, nor does it require writing a description for purely decorative elements that carry no data. When axis labels already fully express the unit and range, a repeated text description is not required.

Design applicationtreat the encoding description as part of the view's data rather than a piece of copy — it should be generated from the same chart specification, so that changing the mapping changes the description with it. The legend and axes are the default location for carrying an encoding description; products with discrete binning especially need to give the boundary values, because "darker means higher" does not let anyone reverse-engineer which band 47 falls into.

Verification examples

• User side: pick any visual difference in the chart at random and check whether the reader can state which field it represents and how large the difference is.
• Implementation side: change a channel's mapping (switch the scale, change the bin boundaries) without changing the description text, and check whether this is detected as an inconsistency.

CounterexamplesUnder-delivery — a heat map gives only a color band running from light to dark, with no numeric scale at all; over-delivery — every small metric card is forced to carry a complete encoding specification, turning the dashboard into a field dictionary.

Basis and referencesfor visual variables and the data properties they can carry, see R03; for the correspondence between channels and reading tasks, see R01.

VZ1-2A channel's meaning is unique within a single viewMUST¶

In one sentence: Color in one chart cannot mean category in one place and pass/fail in another.

Applies tocases where the same class of visual property is used multiple times within a single view.

Rulewithin one identifiable encoding domain, the same scale or legend mapping MUST NOT change meaning without notice. When multiple mappings coexist in one chart, the reader MUST be able to determine which mapping each class of mark belongs to (through a legend, series identifier, axis-associated label, or mark shape), and different mappings MUST NOT contend for the same value space of the same channel to express different things. When two things genuinely need to be expressed in one chart and the reader cannot determine the assignment, distinguishable different channels MUST be used, or the chart split into multiple views. Multiple scale instances on the position channel (dual axes) is a form of multi-mapping coexistence this rule permits, subject additionally to VZ1-5. This constraint is judged by "whether the reader needs to use both encodings at once within a single reading act," not by "whether the marks belong to the same layer": if the primary data uses red and green for rise and fall, and red is simultaneously used to highlight the currently selected item, the reader will still treat both instances of red as the same thing even though they technically belong to different layers, and this therefore does not comply with this rule. A semantic color MUST NOT share a channel with a categorical color without distinction; when state expression such as selection, hover, or alert must share a channel with data encoding, it MUST be carried by a property outside the data encoding (such as a stroke, a texture, or a positional offset), and must not contend for the same value space of the channel as the data values.

Boundary conditionsthis rule does not forbid one channel simultaneously carrying data meaning and redundant reinforcement — using color and shape together to distinguish the same set of categories is the practice VZ6-1 encourages, and does not constitute "two meanings." In multiple clearly separated subplots (facets), the same channel keeping the same meaning within each subplot is not considered a violation of this rule. The test is "can the reader tell the difference," not "does it belong to the same layer," and not "each class of channel can only bind to one field": the same red simultaneously meaning East China and meaning an alert, with the two indistinguishable, violates this rule; two independent Y axes, each with its own unit and series identifier, do not violate this rule.

Design applicationmaintain a one-to-one "channel-to-meaning" inventory for every chart, reserving state expression (selection, comparison highlight, threshold alert) on a separate property. This constraint is most easily broken in dashboards, because components are developed separately while the reader looks at the whole screen at once.

Verification examples

• User side: point to two places in the chart that use the same channel and ask the reader to explain each one's mapping assignment; it is a failure if the same mapping is misread as different meanings, or if different mappings cannot be distinguished.
• Implementation side: inventory the source of every class of visual-property assignment in the view and check whether the same mapping is driven by conflicting meanings; when multiple mappings coexist, check whether there is a distinguishable legend, axis, and mark assignment.

CounterexamplesUnder-delivery — a line chart uses color to distinguish five regions while also coloring "below target" points red, and red is already East China; over-delivery — out of fear of conflict, all highlighting is forbidden, so once a user selects a line they cannot tell at all which one is selected.

VZ1-3The baseline and scale are faithfulMUST¶

In one sentence: Length and area start from zero; positional-axis truncation, nonlinearity, and reversal must be identifiable.

Applies toviews that represent quantity using a positional axis or a length encoding.

Rulean axis's starting point, tick interval, scale type, and direction MUST match the actual rendering and MUST be identifiable by the reader. Encodings that directly express magnitude as "length or area from the baseline to the endpoint" (ordinary column charts, bar charts, area charts starting from zero) MUST NOT use a baseline that does not start from zero, because the reading basis for this kind of encoding is the size of the mark itself, and truncation directly changes the ratio of the magnitudes; adding a break-axis symbol or a truncation indicator does not make this kind of encoding compliant — the correct disposition is to restore a zero baseline or switch to a positional encoding. An encoding that expresses the difference between two endpoints with length (a range bar, a Gantt bar, an upper/lower-bound band) does not fall within what this rule forbids, but it must state the meaning of both endpoints and the difference semantics that length represents. Encodings that carry quantity with position (line charts, scatter plots) may be truncated, but the truncation MUST be clearly marked and must not be implied only by the axis numbers. Nonlinear scales (logarithmic, power, quantile) and reversed axes MUST be explicitly annotated; mixing different tick densities on the same axis without marking it is forbidden. The choice of tick truncation, nonlinear scale, and axis reversal must have a recorded rationale, and must not be made on grounds such as "it looks better this way" or "the trend is clearer this way."

Boundary conditionsthis rule does not require every chart to start from zero — when displaying quantities such as body temperature, stock price, or pH where zero carries no business meaning, forcing a start from zero would obscure the real change; the test is the encoding method (length/area from a baseline, length as the difference between two endpoints, or position), not the data domain. This rule also does not forbid a logarithmic scale, only requiring that it be identifiable.

Design applicationhand the judgment of "should this start from zero" to the encoding type rather than to aesthetics: if switching to a line chart would allow truncation, that means this chart should not have been a column chart to begin with. A truncation indicator cannot rely on axis numbers alone, because the reader reads the length of the mark, not the numerals on the axis; a break-axis symbol, an explicit "vertical axis starts at X" label, or switching to a dotted-line form can all carry it.

Verification examples

• User side: show the reader a truncated and a complete version of the same data and ask them to estimate "how many times higher is A than B"; if the two versions' estimates differ by an order of magnitude, the truncation was not recognized.
• Implementation side: check whether the axis starting point in the chart specification is jointly determined by the data and the encoding type, rather than silently given by the rendering library's auto-scaling default.

CounterexamplesUnder-delivery — a column chart's vertical axis starts at 90, so a 3% difference looks like a threefold increase; over-delivery — all line charts uniformly start from zero, compressing a temperature curve that fluctuates between 36.5 and 37.2 into a flat line.

Basis and referencesfor the amplification of perceived effect size by truncated axes, see R06; for experimental comparison of truncated axes against other distortion techniques, see R05; for public institutional judgment on when truncation is permissible, see R25.

VZ1-4Area and volume are proportional to magnitudeMUST¶

In one sentence: Twice the magnitude is drawn as twice the area, not twice the radius.

Applies toviews that represent quantity using area, radius, diameter, side length, or three-dimensional volume.

Rulewhen representing quantity with area, the mark's area MUST be proportional to the value; mapping a value directly to radius, diameter, or side length is forbidden, because that inflates the visual magnitude by the square. When representing quantity with three-dimensional volume or perspective solid marks, mapping a value to a linear dimension is likewise forbidden. Using an area encoding for a quantity that needs precise comparison is an inappropriate choice (see VZ1-7); when it must be used, a numeric label or a reachable numeric-reading path MUST be provided, and the reader must not be required to make a quantitative judgment from area alone. This rule applies equally to figures scaled by value in decorative illustrations and infographics, and they are not exempt for being "illustrative."

Boundary conditionsthis rule constrains the conversion from value to area; it does not prescribe the shape of a mark, and does not forbid forms such as bubble charts or treemaps whose primary encoding is area. If symbol scaling on a map adopts a published psychophysical correction scheme (such as scaling by perceived area rather than geometric area), the scheme used and its source MUST be stated, and must not be replaced with "empirical adjustment" as an explanation; the acceptance basis in that case is the declared function, not "geometric area ratio equals value ratio."

Design applicationimplementation errors in area encoding mostly come from the step of "passing the value in as r," which is why this is one of the few constraints worth writing into a chart component's default behavior: a component should default to scaling by area, forbidding a value from directly driving radius or side length; perceptual correction should be implemented only according to the declared function.

Verification examples

• Implementation side: take any two marks and check whether the ratio of their rendered areas equals the ratio of their values; when a declared perceptual-correction scheme is used, check whether it matches the declared function.
• User side: give the reader two marks with values of 1 and 4 and ask them to estimate the multiple. If readers systematically answer 16 times, that means the chart's expression needs improvement (labeling, a reference mark, or switching to a positional encoding) — it does not by itself prove the mapping algorithm is wrong; whether the mapping is correct is determined by the implementation-side check above, and the two are recorded separately.

CounterexamplesUnder-delivery — a bubble chart assigns sales figures directly to radius, so twice the sales is drawn as a circle four times the size; over-delivery — to avoid area encoding, every value on a world map is turned into a column chart stacked on the countries, obscuring the geographic information itself.

Basis and referencesfor area and volume ranking below position and length in reading precision, see R01, R02; for experimental evidence of area inflation as a distortion technique, see R05.

VZ1-5Dual axes and multiple dimensions do not manufacture correlationMUST¶

In one sentence: Two lines sitting close together is because of the data, not because you adjusted the scale.

Applies toviews that present two or more series of different dimensions or different orders of magnitude within the same coordinate system.

Rulewhen a dual axis or multiple dimensions share a chart, the range and alignment of each axis is a designer's choice, not a property of the data; choosing the axis range or starting point so as to make two series appear synchronized or crossing in a way the data does not support is forbidden. Using dual axes MUST satisfy: the dimension, unit, and range of both axes are explicitly labeled; which axis each series corresponds to is distinguishable; and the rationale for the axis range choice can be recorded. Making conclusions such as "these two are highly correlated" or "an inflection point occurs here consistently" that depend on axis alignment is forbidden on a dual-axis chart — when correlation needs to be expressed, switch to facets, normalize to the same dimension, or present the correlation relationship directly. When either axis uses truncation or a nonlinear scale, VZ1-3 must be satisfied at the same time.

Boundary conditionsthis rule does not forbid dual axes. Dual axes for the same dimension in different units (Celsius and Fahrenheit, yuan and 10,000-yuan units) are a matter of scale conversion rather than dual dimensions, and are not subject to this rule's restriction on correlation statements.

Design applicationturn "can we add a second axis" into "what reading does this pair of series need to support": if the reader must compare trend direction, use facets; if the reader must compare relative change, normalize to an index uniformly and declare the base period per VZ4-5; if the reader must see the real co-movement relationship, draw a scatter plot. The genuinely appropriate occasion for a second axis is when the two series are each read independently, not read against each other.

Verification examples

• User side: after changing the secondary axis range, ask the reader to redescribe the relationship between the two lines; if the description changes accordingly, the conclusion was built on axis alignment.
• Implementation side: check whether the secondary axis range follows a declared fixed value or an automatic-range policy; changing the range must not generate a correlation conclusion that depends on axis alignment.

CounterexamplesUnder-delivery — advertising spend and revenue are placed on dual axes, the secondary axis is adjusted until the two lines fit tightly together, and the caption reads "spend drove revenue"; over-delivery — dual axes are forbidden outright, so temperature and precipitation are split into two stacked charts whose horizontal axes are not even aligned, making it harder for the reader to compare them against time.

Basis and referencesfor the influence of axis-range choice on readers' conclusions, see R05, R06; for a controlled experiment comparing dual-scale charts on accuracy and subjective burden, see R27 (its subject is dual-scale rather than dual-dimension, so its applicability is limited); for public criticism of the arbitrariness of dual-axis charts, see R26 (institutional practice and practitioner commentary, not a controlled experiment).

VZ1-6A continuous color mapping is orderedSHOULD¶

In one sentence: A color scale must be rankable by high and low, and must not manufacture a boundary the data does not have.

Applies toviews that use color to represent a continuous quantity (heat maps, choropleth maps, density maps, continuous-color-scale scatter plots, etc.).

Rulea color scale representing a continuous quantity should be perceptually ordered, so that the reader can judge the direction of magnitude from color alone. Orderedness is judged separately by color-scale type: for a sequential scale, check the perceptual order along the single direction of magnitude; for a diverging scale, take the midpoint as the boundary and separately check whether the order is monotonic as each branch moves away from the midpoint, and check whether the positive and negative directions are distinguishable — a diverging scale is typically light at the midpoint and dark at both ends, so its overall lightness necessarily rises then falls, and this MUST NOT by itself be judged noncompliant. Using a color scale that is perceptually non-monotonic (such as a full-spectrum rainbow scale) to represent a continuous quantity that needs a magnitude-order judgment is forbidden, because such a scale manufactures a visual boundary where the value changes uniformly, and also weakens a real boundary where one exists. A diverging color scale should be used only for data with a meaningful midpoint (zero, a target value, a base period), and the midpoint MUST be declared; the basis for choosing among sequential, diverging, and categorical color scales should be recordable. The value range of a color scale should cover the data being expressed, or clearly mark out-of-range values and how they are clipped; a shared fixed range may be used for cross-chart comparison, and when the range automatically scales with the data, the range value must be made visible (see VZ1-1).

Boundary conditionsthis rule constrains occasions where color carries a magnitude judgment; it does not constrain color used purely for categorical distinction, and it does not prescribe a specific color palette. Where an existing domain convention mandates a specific color scale (some medical imaging, some meteorological products), that convention MUST be declared, its reading convention explained, and it must be stated item by item which of this rule's SHOULD-level requirements it exempts; the convention does not exempt the hard clause within this rule that "forbids using a perceptually non-monotonic color scale to carry a magnitude judgment."

Design applicationprioritize adopting sequential and diverging color palettes that have already been publicly validated, and record their source; a custom palette should at least be checked for whether it remains monotonic in grayscale. Whether a color scale is ordered and whether a palette is color-vision-friendly are two different things; the latter is covered in VZ6-1.

Verification examples

• User side: give the reader three evenly spaced colors from the color scale and ask them to rank them and estimate whether the spacing looks equal.
• Implementation side: convert the color scale to grayscale: for a sequential scale, check that lightness is monotonic; for a diverging scale, check each branch's order moving away from the midpoint separately, and separately check whether the positive and negative directions are still readable without color. The grayscale check is a diagnostic tool, not by itself proof of color-vision accessibility (the latter is covered in VZ6-1).

CounterexamplesUnder-delivery — a temperature-distribution map uses a rainbow color scale, and a "boundary" that does not exist in the data appears at the yellow-green transition; over-delivery — every chart uniformly uses only single-hue shading, causing a profit-and-loss chart that should highlight two sides of positive and negative to lose its midpoint information.

Basis and referencesfor the non-monotonicity of the rainbow color scale and the false boundaries it causes, see R04; for the distinction and selection tools among sequential/diverging/categorical palettes, see R21.

VZ1-7Channel precision matches the reading taskSHOULD¶

In one sentence: A quantity people must compare precisely does not belong on the hardest-to-read channel.

Applies toviews that require the reader to make a quantitative comparison, ranking, or ratio estimate.

Rulethe choice of visual channel should match the reading task the chart requires the reader to complete: a quantity requiring precise value comparison should use a channel with higher reading precision (position on a common baseline, length); channels with lower reading precision (angle, area, volume, color lightness) should not be used as the sole basis for a precise comparison. When a low-precision channel is used to carry a quantity that needs a quantitative reading, a reachable numeric-reading path MUST be provided (see VZ6-4). What reading task the chart requires the reader to complete should be explicitly determined, rather than inferred backward from the chart type's default choice.

Boundary conditionsthis rule does not forbid any graphical form, nor does it establish a ranking that "one kind of chart is always superior to another." The known ordering of channel precision comes from controlled experiments under specific tasks, and its scope of applicability is limited: it does not cover every reading task, every data scale, or every reader population, so what this rule provides is a basis for choice, not a substitution checklist. Charts that show overall shape, spatial distribution, or category composition are not out of compliance merely for using a lower-precision channel.

Design applicationwrite down "what question this chart is meant to let people answer" before choosing a channel. For the same data, to answer "which is bigger" use a bar on a common baseline; to answer "what proportion" you can use a pie shape but must give the numbers; to answer "what does the distribution look like" there is no need to pursue point-by-point precision.

Verification examples

• User side: have target readers use the chart to complete the reading task it claims to support, and record error and time.
• Implementation side: check whether each chart's declared reading task and its primary encoding channel are recorded together.

CounterexamplesUnder-delivery — a set of 3D pie charts is used to let people compare the share differences among seventeen categories, with no numbers given; over-delivery — because positional encoding has the highest precision, every distribution and geographic dataset is forcibly turned into bar charts, discarding spatial and shape information.

Basis and referencesfor the precision ordering of basic perceptual tasks, see R01; for its repeated verification and extension in a crowdsourced setting, see R02; for the framework relating data, task, and graphical form, see R18.

VZ1-8Comparative views keep encoding comparableMUST¶

In one sentence: Small multiples placed side by side must not look the same size just because each was scaled independently.

Applies tofacets, small multiples, cross-period side-by-side comparisons, and switchable comparison views.

Rulesubplots that carry a magnitude comparison MUST use a common unit and a comparable scale; when independent ranges are used, this MUST be clearly marked, and a common scale or a numeric comparison entry MUST be provided. The same category MUST keep a stable encoding after filtering, sorting, or paging, and must not be recolored according to its current order of appearance. Dynamic auto-scaling MUST make range changes distinguishable; switching views must not silently change color thresholds.

Boundary conditionsa comparative form may use an independent scale, but its purpose MUST be declared; charts unrelated to the current task are not required to use the same range.

Design applicationa comparison group shares one scale policy and one category mapping. Mark an independent scale next to the subplot's title; when categories are filtered, retain the category identity rather than recoloring by array position.

Verification examples

• User side: compare two small charts whose ranges are 0–10 and 0–100 respectively, and ask the reader to judge the total-magnitude difference; the answer must not be derived from bar height alone.
• Implementation side: after filtering out the first category, check whether the remaining categories' color identities are preserved; after switching the time range, check whether the axes and legend stay in sync.

CounterexamplesUnder-delivery — small charts each fill their own container, so a tenfold difference looks the same; over-delivery — to compare shape, every micro trend chart is forced to start from zero, and the real variation disappears.

Basis and referencesR29; the requirement for stable encoding is derived from the commitment to continuous reading.

3.2 VZ2 Provenance is checkable¶

Every number on a chart is the result of some processing: it was taken at a certain point in time, covers a certain scope, was calculated under a certain definition, aggregated to a certain granularity, and had missing values handled in a certain way. This principle governs whether that processing can be checked by the reader. It does not judge whether the processing is correct — how a metric should be defined, whether missing values should be imputed, are business and statistical decisions; this principle requires that these decisions be declared, be annotated, and not take effect silently when they change.

VZ2-1Data time point and refresh status accompany the chartMUST¶

In one sentence: Whoever looks at the chart can know on the spot what point in time the numbers are from.

Applies toviews that present data that changes over time, or whose data is updated asynchronously in the background.

Rulea view MUST let the reader determine the time point or time range its data corresponds to, and the current refresh status of that data. The time range a dataset covers and the time the data was generated are two different things and MUST be separately obtainable: "sales up to March 31" and "this statistic was run on April 2" MUST NOT substitute for each other. When different parts of the same view have inconsistent data time points, they MUST be marked separately by part, and the most recent time point MUST NOT be used to represent the whole. When data fails to update as expected, some source fails, or the result is a stale cache, that state MUST be presented faithfully, and the view MUST NOT be made to look normal by silently reusing the previous result.

Boundary conditionsthis rule does not require a timestamp on every mark, nor does it require real-time refresh. When the data is itself a static historical archive and this has already been declared at the view level, it need not be repeated chart by chart.

Design applicationtreat "time point" as part of the data returned together with the query result, rather than something inferred by the front end from the current time — the latter gives the wrong time under caching, time zones, and failed retries. Dashboards assembled from multiple sources especially need to mark by source, because a single "real-time" label across the whole screen is this kind of product's most common distortion.

Verification examples

• User side: on a one-screen, multi-source dashboard, ask the reader to state what time each block of data is from.
• Implementation side: inject an update failure for one source and check whether the view displays a failure state or silently shows the previous data.

CounterexamplesUnder-delivery — the dashboard's top-right corner says "real-time," while three of its modules come from last night's batch job; over-delivery — every number is followed by a full timestamp, filling the chart with parentheses.

VZ2-2Metric provenance is obtainableMUST¶

In one sentence: Exactly how "active users" is calculated must be reachable next to the chart.

Applies toviews that present business metrics, statistical metrics, or any quantity that only holds meaning once defined.

Rulethe definition of every metric in a view MUST be reachable from the view, its content covering at least: the calculation method, the statistical scope (population, region, channel, period boundary), the unit and currency, and known exclusions. When a same-named metric uses different definitions in different places within a product, each place MUST separately mark its own definition, and the same name MUST NOT be used to imply the same provenance. A metric's definition MUST share its source with the actual calculation logic; copy MUST NOT maintain a separate description unrelated to the implementation. A quantity whose definition is unobtainable MUST NOT be presented under a definite business name — the raw field may be presented, but it must not be named as a metric the reader would understand by its common meaning.

Boundary conditionsthis rule does not require embedding a complete provenance document inside the chart; reachability suffices (hover, click, sidebar, or link are all acceptable, but must satisfy VZ6-4's requirement for a non-hover path). It also does not require writing a definition for generic mathematical quantities (a count or a sum by itself).

Design applicationbuild the provenance registry as a reference field in the chart specification rather than a piece of descriptive text, so that the failure mode of "changed the algorithm, forgot to change the description" is structurally blocked. Cross-team dashboards especially need to handle same name, different meaning: rather than unifying the name, let each instance expand its own definition.

Verification examples

• User side: pick any metric at random and ask the reader to state who it counts in and who it excludes.
• Implementation side: change a metric's calculation logic without changing its description, and check whether this is detected as an inconsistency.

CounterexamplesUnder-delivery — two departments' dashboards both say "active users," one counted by login and the other by valid actions, and the numbers differ by 30% with no way to check why; over-delivery — a full page of provenance description is spread beneath every chart, drowning the key conclusion.

VZ2-3A change in provenance must be annotatedMUST¶

In one sentence: When a definition changes, that step is not business fluctuation — it needs an explanation.

Applies tocases where a metric's definition, statistical scope, data source, or calculation method has changed, and the view spans the time point of that change.

Rulean unstated change in provenance is one of the most serious distortions in this field: a series spanning the change's time point MUST mark when the change occurred and what changed, and MUST NOT be presented as one continuous, comparable series. How historical data is handled after the change MUST be declared and distinguishable, at minimum among three cases: historical data recalculated under the new provenance, historical data kept under the original provenance, or both coexisting. When historical data is recalculated, silently overwriting values the reader has previously seen is forbidden — a recalculation MUST be identifiable as a revision, and MUST trigger the disclosure obligation in VZ5-6. This rule applies equally when the data source itself issues a revision (correction, restatement, an update to a seasonal-adjustment factor).

Boundary conditionsthis rule does not forbid changing provenance, nor does it require permanently maintaining a parallel calculation under the historical provenance. When a change occurs outside the time range a view covers, it need not be marked within that view. When history has been recalculated under the same provenance throughout and can be checked, it may be shown as a comparable series, but the fact of recalculation MUST be retained; what is forbidden is mixing provenances while passing them off as continuously comparable.

Design applicationstore the provenance identifier as a dimension of the time series, and generate the chart's break markers from it. Any note that "data is not comparable from month X onward" that lives only in a release email will be known to no one three months later.

Verification examples

• User side: give the reader a series spanning a provenance change and ask them to explain why the step appears.
• Implementation side: check whether a provenance-identifier field exists, and whether a cross-provenance query is marked.

CounterexamplesUnder-delivery — the statistical scope changes from "all channels" to "owned channels," the curve drops 40%, nothing is written on the chart, and the team spends three days in meetings tracking down the cause; over-delivery — every minor enumeration-value adjustment gets a break marker on the chart, until a year later the chart is covered in vertical lines.

VZ2-4Aggregation granularity and method are visibleMUST¶

In one sentence: Whether a point is a sum, an average, or the latest value, and whether that stays the same before and after drilling down.

Applies toviews that present aggregated data, and products that provide the capability to drill down, roll up, or change time granularity.

Rulefor every aggregated quantity in a view, its aggregation granularity (grouped by which dimension, by which time unit) and aggregation method (sum, average, median, distinct count, latest value, weighted average and its weights) MUST be obtainable. An operation that changes granularity (drill down, roll up, switch time unit) MUST keep the aggregation method unchanged, or clearly disclose the change; silently switching aggregation method after drilling down, causing the upper- and lower-level values to lose additivity, is forbidden. When an upper-level aggregate does not equal the sum of the lower-level detail (due to deduplication, weighting, rounding, or filtering), the source of the difference MUST be explained, and the reader MUST NOT be left to guess. Aggregation can reverse the relationship within a group (the same trend runs in the opposite direction within each group compared with the combined whole); when a product provides an aggregated view, it should make the grouped view reachable.

Rulea ratio aggregate MUST be recalculated from its declared numerator, denominator, or weights; averaging each group's percentage directly and passing that off as the overall ratio is forbidden. When joining data produces duplicate rows, the deduplication key and join relationship MUST be checkable; the note that the total and the detail are non-additive must be carried through to exports and equivalent paths as well.

Boundary conditionsthis rule does not prescribe which aggregation method should be used, nor does it require every chart to show detail alongside the aggregate. A non-additive metric (a ratio, a distinct count, a retention rate) is not in violation of this rule for being non-additive, but its non-additivity MUST be knowable.

Design applicationmake the aggregation method and granularity explicit fields in the chart specification and present them in the encoding description (see VZ1-1). Fix the aggregation method especially along a drill-down path: the reader's mental model of "click in to see the detail" is decomposing the same quantity, not switching to a different one.

Verification examples

• User side: ask the reader to sum the items after drilling down and compare against the upper-level value; when they do not match, check whether the chart has an explanation.
• Implementation side: walk the drill-down path and compare whether the aggregation-method definition is consistent at every level.

CounterexamplesUnder-delivery — a monthly view takes the inventory value on the last day of the month, but switching to a weekly view becomes a within-week average, and the two curves do not line up with no indication at all; over-delivery — every granularity switch pops up an explanation box that must be confirmed, interrupting continuous exploration.

Basis and referencesfor the phenomenon of aggregation masking or reversing within-group relationships and its visualization treatment, see R07.

VZ2-5Missing, zero, and not-applicable are expressed separatelyMUST¶

In one sentence: No data, a value of zero, and not applicable are three different things — they must not be drawn as the same line.

Applies toviews whose data contains missing values, nulls, zero values, or structurally not-applicable values.

Rulea missing datum, a value of zero, and an item that is structurally not applicable MUST be visually distinguishable; presenting them uniformly as zero, blank, or an unmarked break is forbidden. The disposition applied to missing values (exclusion, zeroing, forward-fill, interpolation, model imputation) MUST be declared; when imputation is used, an imputed value MUST be distinguishable from an observed value, and MUST NOT enter a conclusion statement that depends on observed values. A missing segment within a series MUST be identifiable; bridging a missing interval with a direct connecting line without marking it is forbidden. When the proportion of missing data reaches a level that affects reading, that proportion MUST be made obtainable.

Rulea value suppressed for confidentiality or permission reasons MUST be distinguished from a missing value; only the disclosure status that has been authorized may be presented, and a suppressed value must not be exposed through a tooltip, a download, or a difference against a total. A zero denominator, an illegal operation, or a failed query MUST NOT be rendered as 0%. Numeric rounding affects display only; comparison and summation MUST use the declared calculation precision; when a value displays as zero but is actually nonzero, higher precision or a threshold expression should be provided as the task requires.

Boundary conditionsthis rule does not prescribe which missing-value disposition should be used, nor does it forbid imputation. A view with complete data and no missing values may simply record "not applicable."

Design applicationa line chart's default of connecting straight across a missing interval is a rendering library's most common default distortion, and is worth changing at the chart-component level. Distinguishing the three states need not depend on color — a broken line, a gap, a dedicated marker, and grid shading can all carry it, and this is more consistent with VZ6-1.

Verification examples

• User side: construct data containing missing, zero, and not-applicable cases, and ask the reader to point out where each appears on the chart.
• Implementation side: inject an entire missing segment and check whether the line is drawn straight through it, and whether the summary treats the missing values as zero in the denominator.

CounterexamplesUnder-delivery — a region failed to report for the month, and the chart draws it as zero, making it look like the business dropped to nothing; over-delivery — every missing point pops up an explanatory bubble, and a chart with a 15% missing rate is covered in prompt markers.

Basis and referencesfor the effect of different missing-value dispositions on reader judgment and confidence, see R08.

VZ2-6A derived quantity states its algorithmSHOULD¶

In one sentence: Year-over-year change, smoothing, seasonal adjustment, normalization — the algorithm and base period must be statable.

Applies toviews that present a quantity derived by calculation from raw data: year-over-year, period-over-period, moving average, indexation, seasonal adjustment, cumulative value, growth rate, share, standardized score, and the like.

Rulea derived quantity should make its calculation method obtainable, including the algorithm, the window length, the base period or benchmark, and how the boundary is handled (how the calculation proceeds when the start or end of the series has fewer points than the window). Presenting a processed amplitude as an unprocessed fluctuation amplitude is forbidden — smoothing inherently changes the observed volatility; what this rule requires is that the processing be disclosed, not that the processing have no effect on the reader's judgment. When a moving average, seasonal adjustment, or other smoothing is applied, the original series should be made reachable (when deviating from this, record the reason and alternative per the SHOULD deviation discipline); presenting only the smoothed result and stating it as the observed value is forbidden. An indexed series MUST declare its base period and base-period value (see also VZ4-5). When derived quantities placed side by side in the same chart use different windows or different base periods, they must be marked separately.

Boundary conditionsthis rule does not prescribe which derivation algorithm should be used, nor does it require the raw and smoothed series to be shown together by default — reachability suffices. For a derived quantity whose algorithm is already prescribed by industry or regulation (such as a specific financial performance calculation convention), follow that prescription and declare the rule source it is based on.

Design applicationmake the window length and base period a visible annotation on the chart rather than an implicit default — the words "7-day moving average" alone eliminate a great deal of misreading. Boundary handling is most easily overlooked: when the far-right end of a series has fewer points than a full window, if the average is still taken over the available days, the most recent few points will not be comparable to the earlier ones.

Verification examples

• User side: ask the reader to state how long a window this smoothed curve uses, and whether the latest point is already complete.
• Implementation side: check whether the calculation at the series endpoints uses the same window as the middle points; if not, check whether this is marked. The denominator of a ratio, weights, aggregation level, and base-period changes are verified together with the chart's conditions; visual regression and metric-calculation regression are run separately — a chart library rendering successfully is not evidence that the analytical conclusion is correct.

CounterexamplesUnder-delivery — a chart shows a curve smoothed to the point of near-flatness, titled "actual usage," without stating it is a 30-day moving average; over-delivery — raw, smoothed, seasonally adjusted, and year-over-year lines are all overlaid on one chart, each with its own axis, so the reader cannot tell which is the primary line (and this also violates VZ1-5).

VZ2-7Binning and data reduction preserve a basis for readingMUST¶

In one sentence: If the chart only draws part of the data, it must not let people think they are seeing all of it.

Applies tohistograms, density plots, cluster plots, map classification, and views that use sampling, downsampling, or approximate computation.

Rulebinning MUST make the boundaries, endpoint-inclusion rule, and the meaning of count or density obtainable; when an unequal-width histogram expresses frequency, its area MUST correspond to frequency, and must not use raw count as bar height in a misleading way. Sampling, downsampling, clustering, and approximate aggregation MUST each be marked with their method and coverage, and must not be labeled generically as "display optimized." Rendering reduction MUST NOT silently change the data used to calculate metrics, shares, rankings, or alerts; a calculation that depends on a reduced result MUST be marked as approximate and its limitations explained. When zooming causes a change in binning or granularity, the corresponding note MUST be updated.

Boundary conditionsfull rendering is not required; a query of the full data or an equivalent summary can be provided on demand. Promising that sampling preserves all anomalies is forbidden unless a coverage mechanism and validation already exist. A map using raw totals versus normalized ratios MUST declare its denominator, and the two must not be called by each other's name.

Design applicationmark the chart-level summary as "sampled display" or "aggregated by interval," and provide the method and coverage in the detail; when zooming to a finer granularity, update the note accordingly, while the raw metric continues to be calculated by the full query.

Verification examples

• User side: view the same data at different bin widths and sampling rates, and locate the raw or finer-grained authorized data; the reader must be able to distinguish "not shown" from "does not exist."
• Implementation side: inject a single-point spike, unequal-width bins, and a long-tail category; check the data source, bin boundaries, and export notes for summaries and alerts.

CounterexamplesUnder-delivery — downsampling drops a spike but still reports "no anomaly"; over-delivery — ten million points are all drawn at once for completeness, and the result is neither readable nor operable.

Basis and referencesR30; the limits on performance reduction are derived from the requirement that metrics and presentation stay consistent.

VZ2-8Time and comparison periods are clearly definedMUST¶

In one sentence: Same day, same week, and year-over-year must all use clearly statable time boundaries.

Applies tocross-time-zone views, weekly/monthly aggregation, rolling windows, year-over-year/period-over-period comparisons, and current-period comparisons.

Rulea time convention MUST include the time zone, the calendar or fiscal period, the start and end boundaries, and the interval-endpoint rule. A calendar week's starting day, a rolling duration, and a natural period MUST NOT be conflated; daylight saving time and leap days are handled per a declared rule. A comparison between periods of unequal completeness MUST mark its coverage progress, and MUST provide access to the same-completed-portion of the comparison period or to a comparable complete period; treating a partial period directly as a decline from a complete period is forbidden. When changing the time zone changes the bucketing, the data MUST be recalculated and disclosed, not just have its label changed.

Boundary conditionsa time zone need not be shown at every point; it can be layered across the chart-level summary and the detail. Changing only the language or date format should not change the statistical scope.

Design applicationplace the time zone, period, and completeness summary next to the time selector; sharing and export reuse the same time definition. A fiscal week should not be labeled merely as "week."

Verification examples

• User side: have readers in different time zones explain the date boundary and comparison period of the same shared view.
• Implementation side: check bucket assignment, the denominator, and export-condition consistency using data that crosses midnight, a daylight-saving-time switch, and a leap day.

CounterexamplesUnder-delivery — after switching to the local time zone, only the axis label changes while the daily total is still calculated under the other time zone; over-delivery — every point carries a full calendar-definition annotation, obscuring the trend.

Basis and referencesR31; the requirement for period comparability is derived from the commitments to provenance and completeness.

3.3 VZ3 Uncertainty is not omitted¶

A point on a chart could be the result of a full census, or it could be an estimate from 40 survey responses, the output of a model, or a forecast that has not yet happened. This principle governs whether these three remain distinguishable on the chart. Uncertainty is not a decoration to be considered after the chart is finished; it is part of the number itself: omitting it does not make the conclusion clearer, it only turns "roughly how much this is" into "this is exactly how much." This principle does not judge whether the statistical method itself is appropriate — which interval to use, whether a model is applicable, are decisions for statistics and domain expertise; this principle requires that these properties be presented faithfully, and in a form the reader can actually use.

VZ3-1An estimate is not presented as a certaintyMUST¶

In one sentence: A quantity computed from sampling or a model must be distinguishable as an estimate, with its error information obtainable alongside the chart.

Applies toviews that present a sampled statistic, a model output, an imputed value, a forecast value, or any estimated quantity with known error.

Rulepresenting an estimate in the same visual form as an observed value without distinction is forbidden. When the product already has uncertainty information for the quantity (a confidence interval, a prediction interval, a standard error, a posterior distribution, model residuals, sampling error), that information MUST be made obtainable alongside the chart; presenting only the point estimate while leaving the interval in an export file or the back end is forbidden. When the product does not have uncertainty information, that fact MUST be made knowable; presenting an estimate as a certainty by default on the grounds of "no interval data" is forbidden. "Obtainable" does not mean "must be drawn on the chart" — an interval band, a whisker, a quantile shading, a label next to the value, or expandable detail can all carry it, but it must not exist only outside the product. For a key conclusion used to influence a decision, the uncertainty of the estimate it is based on MUST be obtainable within the same view that yields that conclusion, and the reader must not be required to switch elsewhere to look it up.

Boundary conditionsthis rule does not require fabricating an interval for a quantity such as a full census, an accounting record, or a system count, for which no sampling error exists. "Not applicable" is judged item by item against the declared quantity and the reading task, with a stated reason, and is not exempted wholesale by the category of data source: the same full count, used to describe "50 entries have been recorded this month," may be marked not applicable; when it is used to infer a future occurrence rate or to make a cross-period comparison, that not-applicable status does not automatically carry over — process randomness, known coverage and measurement error, and the possibility of a later revision (see VZ5-6) must still be assessed under this rule. No sampling error does not mean no uncertainty; when the situation is unknown, record "unknown," not "not applicable." This rule also does not prescribe which uncertainty measure to use; that is a statistical judgment.

Design applicationmake "whether this quantity has uncertainty information" a field in the data contract rather than a one-off design discussion — when this field is missing, a chart component has no way to judge whether an interval should be drawn, and defaults to a solid line; this is the most common failure mode of this rule. In a dense chart, a point estimate may be presented first with the interval placed in an expandable location, provided that the fact that "an interval exists" is itself visible on the chart.

Verification examples

• User side: ask the reader to point out which quantities on the chart are observed and which are estimated; being unable to answer is a failure of this rule.
• Implementation side: inject a dataset without an uncertainty field, and check whether the system explicitly declares "no uncertainty information" or silently renders it as a certainty.

CounterexamplesUnder-delivery — a satisfaction survey is drawn as a choropleth map by city, and three cities each with only a few dozen samples are drawn in exactly the same way as cities with the full sample; over-delivery — every bar gets a whisker added, including quantities drawn from complete accounting records with zero-width intervals, so readers instead learn to ignore all whiskers.

Basis and referencesfor the reasons and consequences of the systematic omission of uncertainty in practice, see R10; for a survey of forms of uncertainty expression, see R11.

VZ3-2The meaning of an uncertainty representation is resolvableMUST¶

In one sentence: Whether this whisker is a standard deviation, a standard error, or a 95% interval must be clearly stated.

Applies toviews that present uncertainty, error, or an interval in any graphical form.

Rulefor every graphical element on a chart that represents uncertainty, its statistical meaning (standard deviation, standard error, confidence interval and its level, prediction interval, quantile range, interquartile range, posterior credible interval, min-max range) MUST be obtainable. "Error bar" is not a meaning, it is a shape: the same shape can carry at least five mutually inequivalent quantities, and an error bar with an undeclared meaning does not satisfy this rule. How the interval is calculated (normal approximation, bootstrap, exact method) should also be obtainable when a difference in result could affect the reading. Multiple uncertainty representations placed side by side within the same view MUST use the same meaning, or be marked separately; mixing a standard-error whisker with a confidence-interval band on one chart without distinction is forbidden.

Boundary conditionsthis rule does not require a permanently displayed statistical definition next to the mark; reachability suffices (a legend, an explanatory area, or expandable detail are all acceptable, but must satisfy VZ6-4). This rule does not prescribe which measure should be used.

Design applicationcarry the type and parameters of the uncertainty (such as "95% confidence interval, bootstrap with 2,000 resamples") as an attribute of the data that flows with the value, with the legend's description generated automatically. Any product that relies on a manually written phrase in the chart title such as "includes error bars" will leave a stale description behind the moment the statistical method changes.

Verification examples

• User side: ask the reader what each end of the whisker represents; an answer like "roughly the range of fluctuation" indicates the meaning was not conveyed.
• Implementation side: change the interval-calculation method and check whether the legend's description changes accordingly.

CounterexamplesUnder-delivery — a row of whiskers on an academic-style chart, with the caption saying only "error bars represent uncertainty"; over-delivery — every chart is accompanied by a complete statistical-methodology explanation that takes up more space than the chart itself, and readers skip the whole explanation.

Basis and referencesfor cases where readers confuse different interval types, and a survey of uncertainty-expression research, see R11.

VZ3-3Small samples and unstable values have a dispositionMUST¶

In one sentence: A cell whose denominator is 7 must either be marked, or produce no number at all.

Applies toviews that present ratios, proportions, averages, rankings, or color scales sliced by dimension, especially products that allow users free drill-down and cross-filtering.

Rulea product MUST define a disposition for values with too small a sample size or that are statistically unstable, and MUST make that disposition distinguishable on the view. Acceptable dispositions include: marking as unstable, hiding the value, merging to a coarser granularity, or presenting a wider interval; presenting a small-sample cell in exactly the same way as a large-sample cell with no marking at all is forbidden. The threshold and criteria for judging instability (minimum denominator, a ceiling on relative standard error, minimum cell count) are determined by the product according to its data and purpose, and the basis MUST be recorded; these guidelines give no universal value. Drilling down and cross-filtering rapidly shrink the denominator, and a product that provides free-form slicing MUST make this disposition take effect equally on the sliced results, not only on preset views. For small cells that involve individual identifiability, the suppression rule is executed separately under the applicable privacy and statistical-disclosure requirements; these guidelines do not substitute for that determination.

Ruleinterval width MUST come from the declared statistical method; artificially widening an interval for the sake of visual caution is forbidden. Statistical-instability marking and privacy suppression are judged separately; clearing the former MUST NOT cancel the latter.

Boundary conditionsthis rule does not require hiding all small-sample data — hiding and marking are two legitimate dispositions, and which to choose depends on the purpose. This rule gives no threshold value, and does not judge whether the stability criterion adopted is statistically appropriate.

Design applicationput the threshold determination at the data layer rather than the rendering layer, so that a result on any drill-down path carries this "is it stable" marker with it. Leaderboards and "highest/lowest" labels are where small-sample failures concentrate most: the group with the smallest denominator is the one most likely to top the chart.

Verification examples

• User side: follow the finest drill-down path to a cell with an extremely small denominator, and check whether the reader can tell this number is unreliable.
• Implementation side: construct a group with a single-digit denominator and check whether it carries a marking in the color-scale chart, the leaderboard, and the export file alike.

CounterexamplesUnder-delivery — after drilling down three levels by "city × channel × audience," a cell shows a 100% conversion rate because its denominator is 1; over-delivery — every cell below the threshold is uniformly hidden with no statement that it exists, leading readers to think these groups have no business at all.

Basis and referencesfor the presentation threshold and suppression practice applied to small-denominator ratios in public statistics, see R12 (an institutional standard whose numeric thresholds are set for a specific statistical system, and are not transplanted here as a general rule).

VZ3-4Forecasted and observed are separately distinguishableMUST¶

In one sentence: History and forecast can share a chart, but their nature and the boundary between them must be distinguishable.

Applies toviews that present historical observed data together with a forecast, target, extrapolation, or scenario-simulation result within the same view.

Rulean observation that has already occurred and a forecast that has not yet occurred MUST be visually distinguishable, and the time point of the boundary between them MUST be identifiable. The forecast portion MUST make its nature obtainable: whether it is a model extrapolation, a manually set target, or a scenario assumption; a model forecast should also present its prediction interval (see VZ3-1). Presenting a target value, a budget value, or a planned value as an unmarked extension of the same series as the observed values is forbidden — a target is not an estimate of the future, it is a decision. When the current period's data is not yet complete (only 9 days have passed this month), presenting the incomplete period side by side with complete periods without marking its incompleteness is forbidden, as is completing the current period through proportional extrapolation without disclosure.

Boundary conditionsthis rule does not forbid drawing a forecast on the same chart, nor does it require the forecast to be split into a separate chart from history. The definition of a complete data period (by calendar day, by settlement day, by data arrival) is declared by the product; this rule only requires that it be declared and applied consistently.

Design applicationan incomplete current period is the dashboard's most consistent source of misreading: the last bar on a monthly column chart is always short, so at the start of every month someone thinks the business is declining. A dashed line, blank space, shading, and a "current progress 9/30" label can all carry it — a dashed line alone is not necessarily sufficient, since line style often fails in thumbnails and print.

Verification examples

• User side: open the monthly comparison chart at the start of the month and ask the reader whether the last bar can be compared with the earlier ones.
• Implementation side: set the system clock to the second day of a period and check whether the current period is marked incomplete.

CounterexamplesUnder-delivery — the last three points of an annual trend chart are model forecasts, drawn in the same solid line and color as the preceding twelve points; over-delivery — the forecast portion is made into a separate layer that requires an extra click to display, so the default view the reader sees contains no outlook into the future at all, even though that is exactly what this chart is for.

VZ3-5A difference that has not reached a distinguishable degree is not stated as a differenceSHOULD¶

In one sentence: Rankings, color scales, and "highest" labels must not be built on noise.

Applies toviews that rank, compare, or label a set of quantities as higher/lower or as different, and products that auto-generate conclusion copy.

Rulegenerating a definitive comparative statement (such as "A outperforms B" or "C leads significantly") based solely on the relative size of point estimates, or solely on whether the intervals of two individual estimates overlap, is forbidden. The overlap of individual intervals is not a substitute for a difference test — two estimates' respective 95% intervals can overlap while the interval of their difference does not contain zero; a standard deviation, an interquartile range, a prediction interval, and a mean confidence interval also do not share the same criterion. Distinguishability is given by a determination rule declared by the person responsible for the statistics (a difference or ratio and its interval, a correlation structure, a testing method, or a declared business threshold).

A comparison result MUST distinguish three outcomes: supports a difference / insufficient evidence obtained / not evaluated; neither of the latter two is equivalent to "the two are equal," and stating them as equal or as a parallel fact is forbidden. This rule applies equally to auto-generated conclusion copy, alerts, and insight summaries. When a ranking genuinely needs to be presented, it should make a relationship already determined to be indistinguishable visible (indicate the lack of distinction through a connecting line, an interval, or a tier hint, without stating the tier as numerical equality); "interval-overlap marking" serves only as a presentation of uncertainty, not as a criterion for distinguishability. Within the scope of these guidelines, the word "significant" should be used only where the corresponding statistical judgment has actually been made, not as an emphasis word.

Ruledescribing the size order of a definite accounting record does not require enforcing a significance test; the applicable statistical criterion is adopted only when inferring toward a population or the future, or when claiming a statistical difference. When batch-searching groups and automatically picking out anomalies, the search scope and multiple-comparison handling MUST be declared, or the results MUST be limited to leads pending review; correlation must not be stated as causation. A business threshold and statistical evidence must be expressed separately.

Boundary conditionsthis rule does not require a product to run a statistical test on every comparison, nor does it judge whether the testing method adopted is appropriate; the criterion is whether the product already has information sufficient to judge distinguishability and has failed to use it. Providing a browsing order by raw value size is permitted, provided it is labeled as a browsing order and the estimated nature of each quantity is retained, not stated as a conclusion. A rough ranking used for operational monitoring, if already declared as not a basis for conclusions, is not subject to the full restriction this rule places on the form of the statement.

Design applicationwhere this constraint really lands is automatic insight features. A system that generates sentences such as "East China grew fastest this week" from numeric differences will consistently report noise as news, and because its tone is definitive it gets cited more readily than the chart itself. Adding a distinguishability criterion to the insight generator changes what conclusion the reader gets more than adding whiskers to the chart does.

Verification examples

• User side: give the reader a ranking of values whose intervals overlap heavily and ask them to judge whether the first place is genuinely higher than the third.
• Implementation side: inject perturbations according to a pre-declared data-generation hypothesis and check whether the conclusion follows the difference criterion; the conclusion is allowed to change when the real difference changes or crosses the threshold.

CounterexamplesUnder-delivery — an automatic weekly push of "best-performing store this week," when in fact the differences among the top ten are entirely within normal day-to-day fluctuation; over-delivery — because the difference is not significant, no ranking at all is presented, and operations staff lose the basic ability to browse by size.

Basis and referencesfor readers' tendency to treat a point estimate as a certainty when uncertainty is not expressed, see R10, R11.

VZ3-6The form of uncertainty expression matches the reading taskSHOULD¶

In one sentence: Adding error bars does not mean the reader has understood the uncertainty.

Applies toviews that require the reader to make a judgment based on uncertainty (comparing whether there is a difference, estimating the likelihood of exceeding a threshold, judging whether a trend holds).

Rulethe form of uncertainty expression should match the reading task the chart requires the reader to complete; presenting uncertainty does not mean that uncertainty has been used by the reader in their judgment. When the reader is required to estimate "the likelihood of exceeding a certain value," giving only the upper and lower bounds of an interval should not serve as the sole expression; when the reader is required to compare whether two groups differ, a directly comparable form should be made available (a difference or ratio and its interval) rather than requiring the reader to eyeball the overlap of two whiskers. A product's choice of uncertainty-expression form should have a recordable rationale, and its usability should be verified on target readers; using "error bars have already been drawn" as sufficient proof of satisfying VZ3-1 is forbidden. When adopting forms such as a quantile dot plot, a density strip, or a hypothetical-outcome animation, how to read them MUST be made obtainable.

Boundary conditionsthis rule does not prescribe which form should be used, nor does it hold that any one form is universally superior to another. Existing research comparing the effectiveness of various forms depends on specific tasks and populations, and its conclusions cannot be directly transplanted into a universal ranking; what this rule provides, therefore, is a basis for choice and a verification requirement, not a checklist of forms.

Design applicationwrite down first "what question the reader needs to use this uncertainty to answer." To answer "will this exceed budget," giving the probability of exceeding the threshold directly is closer to the task than giving an interval; to answer "are these two groups the same," drawing the distribution of the difference is closer to the task than drawing two whiskers. Products aimed at non-expert readers especially need to verify whether the reading is understood, rather than copying academic chart conventions.

Verification examples

• User side: have target readers use the chart to answer the uncertainty judgment it claims to support, and record the distribution of judgments and any systematic bias.
• Implementation side: check whether every chart containing uncertainty records the reading task it declares support for.

CounterexamplesUnder-delivery — a dashboard aimed at business staff copies the standard-error whiskers from an academic paper, and in actual use everyone looks only at the top of the bar; over-delivery — a metric that only needs to convey "roughly in this range" is given an animated sampling demonstration, and readers spend more time understanding the demonstration than the metric.

Basis and referencesfor schemes that present uncertainty through sampling animation and their applicable tasks, see R09; for a survey matching forms of uncertainty expression to tasks, see R11.

3.4 VZ4 Analytical conditions are visible and removable¶

Analytical actions continually change "which part of the data this chart currently shows." Filtering out three regions, brush-selecting a time span, drilling down to city level, sorting by growth rate, using last year as the base period — each step layers another condition onto the current view, and the sum of these conditions determines the meaning of that number on the chart. This principle governs whether these conditions are visible, whether they are removable, and whether the semantics of different analytical actions get mixed together. It governs the view conditions at this current moment; the process from the starting point to this moment belongs to VZ5. A selection MUST clearly indicate whether it is highlighting, filtering, or a pending-submission range; removal and submission MUST have an identifiable result.

VZ4-1The currently effective conditions are completely visibleMUST¶

In one sentence: Which part of the data this chart currently shows must be statable on the chart.

Applies toviews that provide filtering, time-range selection, grouping, dimension switching, drill-down, or any capability that changes the data range.

Ruleall conditions currently in effect on a view MUST be visible; "complete" is the core of this rule: conditions explicitly set by the user, conditions applied by the system by default, conditions carried in from an upstream page or a jump link, and filters applied by permission or data-visibility scope, all belong to the currently effective conditions and MUST all be obtainable. An implicit filter that affects the result but appears in no condition statement anywhere is forbidden — defaulting to only the last 30 days, defaulting to excluding internal accounts, defaulting to filtering out test data, automatically scoping to the current user's organization — all of these MUST be visible. The test for "visible" is whether the reader can reach it while looking at the chart, not whether it can be dug out deep within a settings panel. When data is restricted by permission, it MUST be stated that the result represents only the currently authorized scope; the existence, name, count, or specific filter predicate of an unauthorized object must not be leaked.

Boundary conditionsthis rule does not require every condition to be permanently laid out flat on the chart; when there are many conditions, they may be collapsed, but the number and existence of the conditions MUST be visible in the collapsed state, not hidden entirely. An inherent limitation of the product's scope itself (a product that serves only a single region) may be declared at the view level and need not be repeated chart by chart.

Design applicationmake "the current view's conditions" a structured description rather than several scattered component states — it is simultaneously the content source for what VZ5-3 requires an export to carry, and the basis for what is readable on the VZ6-5 equivalent path. Default conditions are where this rule most commonly fails: they are "a reasonable default" at development time and "a filter nobody knows about" at use time.

Verification examples

• User side: ask the reader, without opening any settings panel, to list every condition currently in effect on the chart, and compare against what the system actually applies.
• Implementation side: inventory every filter condition the query actually issues, and check item by item whether each has a corresponding presentation in the interface.

CounterexamplesUnder-delivery — a report defaults to excluding refunded orders, with the condition written only in a requirements document, and finance spent two weeks reconciling accounts against it; over-delivery — all seventeen conditions are laid out flat above the chart, taking up half the screen, and the reader cannot find the two that actually matter.

Basis and referencesfor the principle that analytical actions should proceed from overview to detail while keeping the current scope visible, see R13.

VZ4-2Each condition can be removed individuallyMUST¶

In one sentence: With five filters applied, you must be able to remove just one of them.

Applies toviews that allow multiple conditions to be applied at once.

Ruleevery currently effective, user-controllable condition MUST be individually removable; providing only a single "reset all" exit is forbidden. After removing one condition, the remaining conditions MUST stay unchanged; silently resetting other conditions or returning to the initial view on the pretext of removing one is forbidden. When conditions have dependencies (drilling down to city depends on a selected province), the effect of removing an upstream condition on downstream conditions MUST be predictable and disclosed; silently discarding downstream conditions without explanation is forbidden. A non-removable condition (a permission restriction, an inherent product scope) MUST be visually distinguishable from a removable condition; displaying a non-removable condition as clickable when it does nothing is forbidden. The ability to clear all user-controllable conditions MUST exist, but must not be the only path; fixed scopes and permission restrictions must still take effect.

Boundary conditionsthis rule does not require that every combination of conditions can be removed down to any intermediate state, nor does it require that removal be undoable without limit (undo and state rollback are covered in VZ5-2). When conditions have a hard dependency, removing them together after disclosure is permitted.

Design applicationcondition capsules that each carry their own removal entry are a common approach, but they must cover "conditions carried in by a jump link" and "system default conditions" — these two categories are often implemented as invisible and non-removable, leaving the reader no way out except re-entering the page.

Verification examples

• User side: apply five conditions and ask that only the third be removed, then observe whether the other four remain.
• Implementation side: walk through the condition types and check whether each has an independent removal path, and whether the remaining query conditions stay unchanged after removal.

CounterexamplesUnder-delivery — jumping from an alert detail into the analysis page carries in an invisible, non-removable alert-object filter, and the user believes they are seeing the full dataset; over-delivery — every condition is given four operations — remove, invert, lock, and temporarily disable — making the condition area more complex than the chart.

VZ4-3The scope of a linked action is determinableMUST¶

In one sentence: Brushing on this chart — which charts change and which do not must be knowable.

Applies toproducts composed of multiple views with linking among them (dashboards, multi-view analysis interfaces, coordinated views).

Rulethe scope of a single analytical action MUST be determinable: after a condition is applied on one view, which views change as a result and which do not must be determinable by the reader. Letting the reader infer the linking relationship by observing whether a number happened to change is forbidden. A view that did not participate in the linking must be distinguishable from a view that did participate but whose data happened not to change, otherwise the reader will misread "not linked" as "this part is unaffected." When the direction of linking is asymmetric (A affects B, B does not affect A), that asymmetry MUST be knowable. When linking causes some view to have no data, it MUST be presented as "no data under the current conditions" rather than as blank or an initial state. When a cross-view linking scope is affected by a view being exported or shared individually, handle it per VZ5-3 and VZ5-4.

Boundary conditionsthis rule does not require that all views must be linked, nor does it prescribe a default on/off for linking. A product with no linking at all among its views may simply record "not applicable."

Design applicationthe difficult part of the mental model for multi-view linking is not "clicking changes something," but "which parts didn't change." Making the linking relationship a visible structure (a grouping box, a connection indicator, a unified condition area) is more stable than highlighting case by case. A selection MUST be bound to a stable data identifier or an explicit interval predicate, not to a sorted screen position; after reordering or zooming, the selected objects are retained, and objects that have left the result set are marked as no longer visible or cleared per a declared policy.

Verification examples

• User side: after brush-selecting on one chart, ask the reader to point out which charts on screen were affected.
• Implementation side: construct a case where linking occurs but each view's data happens not to change, and check whether the interface can still indicate that these views participated in the linking.

CounterexamplesUnder-delivery — a dashboard has six charts, clicking a bar in the first affects three of them while the other three don't budge with no explanation at all, and the user keeps clicking to probe what's connected; over-delivery — every linking event plays a highlight animation and pops up a notice across all related views, so the interface keeps flashing during continuous exploration.

Basis and referencesfor the mechanism of brushing and view coordination and its design space, see R14, R15.

VZ4-4The semantics of zoom, drill, and filter are kept separateMUST¶

In one sentence: A change to the viewport, to granularity, and to the calculated data range must each be separately distinguishable.

Applies toviews that provide two or more of zoom, drill-down, and filter capability at once.

Rulechanging the viewport (zoom, pan), changing granularity (drill down, roll up, switch time unit), and changing the dataset (filter, exclude) are three different actions, and their semantics MUST be kept separate: zooming MUST NOT silently change the dataset used in calculation — after zooming in on a time axis, whether data outside the axis range still participates in aggregation, smoothing, cumulative totals, and percentage calculations MUST stay consistent and knowable. The conditions applied by the three actions MUST be separately distinguishable in the condition area (see VZ4-1), and separately removable (see VZ4-2). When the same gesture or the same control carries two semantics at once, the current semantic MUST be determinable; letting the same scroll-wheel action mean zoom in one chart and paging in another with no indication at all is forbidden. When drilling down causes a change in aggregation method, handle it per VZ2-4.

Boundary conditionsthis rule does not forbid implementing zoom as a filter on the data range ("zoom is filter" is a legitimate design), but that semantic MUST be declared and applied consistently, and must not be mixed with the other semantic within the same product. This rule does not prescribe the specific form of the gesture or control.

Design applicationpercentages, cumulative values, and moving averages are the litmus test for this constraint: whether the denominator changes after zooming determines whether the number on the same bar suddenly looks different. Making "viewport range" and "calculation range" two explicit fields is more reliable than patching the interaction layer case by case.

Verification examples

• User side: perform a zoom on a chart containing a share value and ask the reader to judge whether the share's denominator changed.
• Implementation side: perform a zoom and an equivalent-range filter separately, and compare whether the aggregation results match; if they do not, check whether this has been declared.

CounterexamplesUnder-delivery — zooming in on the time axis to one week silently turns the chart's "share of the full year" into "share of this week" with no indication at all; over-delivery — zoom, drill-down, and filter are made into three independent tools that require selecting a mode first, so the reader has to switch modes before every exploration.

VZ4-5The comparison baseline is an explicit choiceMUST¶

In one sentence: Who you're comparing against, which period counts as 100, is chosen — not naturally given.

Applies toviews that present year-over-year, period-over-period, comparison against a target, comparison against a base period, indexation, relative change, or any quantity that depends on a baseline.

Rulea comparison baseline is a design choice and MUST be explicitly presented and identifiable: the baseline object (the same period last year, the prior period, a target value, the same group's average, a designated base period), and the baseline's value and time point MUST be obtainable. Presenting the choice of baseline as an inherent property of the data is forbidden — the statement "grew 30%" ceases to hold once the base period is changed, so the baseline cannot be separated from the conclusion (see also VZ5-5). When the baseline itself may change (a target is adjusted, base-period data is revised), the change in baseline MUST be separately distinguishable from the change in the compared quantity; stating a ratio change caused by a baseline shift as a business change is forbidden. When a product allows the user to change the baseline, the current baseline MUST belong to the current view conditions (see VZ4-1) and MUST be individually removable (see VZ4-2); on removal, it MUST return to a declared default baseline or switch to an absolute quantity — outputting a growth rate with no baseline is forbidden. A legally or operationally fixed baseline may be non-removable, but it MUST still be identifiable and its basis for being fixed stated. When the choice of base period materially affects the conclusion, the result under a different base period should be made reachable.

Boundary conditionsthis rule does not prescribe which baseline should be used, nor does it require every chart to provide the ability to change baseline. Where industry or regulation already prescribes a baseline, follow that prescription and declare its source.

Design applicationan indexed chart is where this constraint most needs to be enforced: aligning every starting point to 100 means who appears to rise fastest depends entirely on which day the starting point is chosen. Allowing the base period to be dragged and letting the reader observe the ranking change teaches the role of the baseline better than any text explanation.

Verification examples

• User side: after changing the base period, ask the reader to redescribe each series' relative performance; if the description reverses, the conclusion was built on the baseline choice.
• Implementation side: check whether the baseline exists as an explicit parameter in the chart specification, rather than being hard-coded into the query.

CounterexamplesUnder-delivery — a chart says "3x growth versus the base period" with no way to find anywhere on the chart which day the base period was; over-delivery — every comparison chart forces the user to choose a baseline before they can see any content, slowing down routine monitoring.

VZ4-6Sorting and truncation account for the restSHOULD¶

In one sentence: Showing only the top ten requires an account of where the rest went.

Applies toviews that sort data and present only part of the items (Top N, leaderboards, bar charts truncated by size, category charts with a limited category count).

Rulewhen only part of the items is presented, the existence and scale of the omitted portion should be made obtainable: the number of omitted items, their combined value or share, and the field and direction the sort is based on. Presenting the truncated portion as the whole is forbidden — labeling a "total" on a chart showing only the top ten, or calculating a share from these ten items without stating the denominator's scope, are practices this rule explicitly forbids. A subset share with an explicitly labeled denominator scope is permitted (for example, "32% of the combined top-ten total"), provided the existence and scale of the omitted portion remains knowable. An item grouped into "other" should have its composition reachable; "other" must not be allowed to become a black box that cannot be expanded. When the field the sort is based on does not match the quantity primarily presented on the chart (sorted by sales but the chart draws growth rate), this MUST be made knowable. For items that are tied or whose difference is indistinguishable, see also VZ3-5.

Boundary conditionsthis rule does not require showing every item, nor does it forbid the "other" grouping method; the criterion is whether the omitted portion is knowable, not whether it is displayed. A view with genuinely few categories, all of which are already shown, may simply record "not applicable."

Design applicationmake "other" an expandable tier rather than a dead end. Data with a large long tail is especially dangerous: when the combined top ten accounts for only 12%, a Top 10 chart gives an impression almost unrelated to the data itself.

Verification examples

• User side: give the reader a Top 10 chart and ask them to estimate what share these ten items represent of the whole.
• Implementation side: check whether the denominator of any share or total on the chart is drawn from the whole or from the presented subset.

CounterexamplesUnder-delivery — a Top 10 bar chart of error types is captioned "these ten types account for all errors," when in fact an undisplayed long tail accounts for 60%; over-delivery — all 800 categories are drawn onto one chart, with the first few bars readable and the rest a smear of thin lines.

VZ4-7Query state is consistent with the effective conditionsMUST¶

In one sentence: A new filter that has not finished computing must not let the old result pass itself off as the new one.

Applies tointerfaces with asynchronous filtering, multi-view queries, auto-refresh, and data that returns incrementally.

Rulethe interface MUST distinguish the condition being edited, the condition that has been submitted, and the condition the current result actually reflects. When an old result is retained during loading, it MUST be marked as corresponding to the old condition and its data time point; wrapping an old value in a new condition's title is forbidden. A returned result MUST match the currently valid request and condition; a stale response MUST NOT overwrite the result of a request sent later. First load, no result under the current condition, query failure, permission denial, partial success, and use of a stale cache MUST be distinguishable. A partial success updates only the views to which it applies, and marks which parts cannot yet be jointly compared; cancellation, timeout, and retry MUST NOT be disguised as completion.

Boundary conditionsthis rule does not require all views to return at the same time. Updating chart by chart or submitting as a group is acceptable, but the display of progress must be distinguished from a jointly comparable result; a loading animation by itself is not evidence that a condition has taken effect.

Design applicationthe condition area shows a pending-submission state; when retaining an old chart, write "previous result" next to the chart's title. Once a request completes, update that view's data, title, table, and summary together in one step; the condition can still be modified after canceling a wait.

Verification examples

• User side: rapidly select regions A then B in succession; the user must always be able to tell which region the current value belongs to; on failure, the condition is retained and can be retried.
• Implementation side: make A return later than B, make some chart time out, and let a cache expire; check whether the chart, table, title, summary, and export all use the same result binding.

CounterexamplesUnder-delivery — the condition shows B, but a slow-returning A overwrites the result; over-delivery — every filtering action locks the entire screen, and the user cannot modify the condition or cancel the wait.

Basis and referencesderived from the commitment to result consistency in asynchronous analysis; this belongs to the engineering fault model.

3.5 VZ5 The analytical process is traceable and portable¶

Analysis rarely gets there in one step. A person tries a filter, finds it wrong, switches dimension, drills down, backs out, changes the base period again — the conclusion is the result of this whole string of actions, not of any single click. This principle governs two things: whether this string of actions can be retained and reversed, and whether, once this chart leaves the product (exported, screenshotted, shared, pasted into a report), the conditions under which it holds still travel with it. A chart gets forwarded, and the person forwarding it does not forward the context — this is this field's most consistently stable failure path.

VZ5-1The path to the current view is queryableMUST¶

In one sentence: How one arrived at this point must leave a retrievable record.

Applies toproducts that support multi-step, exploratory analysis (analysis workbenches, self-service BI, data-exploration tools).

Rulethe sequence of operations from the analysis's starting point to the current view MUST be queryable, its content covering at minimum: what condition each step applied or removed, what granularity or encoding it changed, and the time point that step corresponds to. The unit of the record is a user-recognizable analytical action, not an internal event: the dozen or so intermediate states produced by one drag operation count as one step; a log MUST NOT be presented directly as the analytical path. Steps applied automatically by the system (a default condition, an automatic drill-down, a recommended view, a view generated or adjusted by an agent) MUST be distinguishable from steps applied actively by the user. The path record MUST be consistent with the conditions actually in effect; presenting a history that does not match the current view is forbidden. When the system generates a view or a conclusion, the actual input scope, processing steps, generation source, and data snapshot used MUST be recorded; a generation step must not be labeled as a user action.

Boundary conditionsthis rule does not require recording actions such as mouse movement, hovering, and scrolling that do not change view conditions, nor does it require permanently retaining the path. A product that provides only fixed reports and does not support exploration may simply record "not applicable." The retention period is declared by the product.

Design applicationstring the analytical path together with "the current view's conditions" using the same structured description — the path is the change sequence of the conditions, and only sharing a source keeps the two from drifting apart. The distinction between automatic and manual steps is the half of this rule most easily overlooked: what a reader most needs to know when looking back is often exactly "did I add this filter, or did it add itself."

Verification examples

• User side: after completing a roughly ten-step analysis, ask the reader to state, based on the path record, what a particular intermediate step did.
• Implementation side: insert a system-applied condition into the path and check whether it is marked as a non-user action.

CounterexamplesUnder-delivery — after half an hour of exploration, no one can remember at which step that anomalous number appeared, and the analysis has to start over; over-delivery — every hover and every scroll is logged into the path, so a five-minute analysis produces four hundred records that cannot be read.

Basis and referencesfor the typology and uses of analytical-process retention, see R16; for usable forms of graphical history, see R17.

VZ5-2One can return to a prior analytical stateMUST¶

In one sentence: Stepping back should not mean starting over from scratch.

Applies toproducts that support multi-step, exploratory analysis.

Rulethe user MUST be able to return to a prior analytical state, and the unit of that rollback MUST be consistent with the analytical action recorded by VZ5-1. A rollback MUST restore the complete set of view conditions, not only part of it (rolling back only the filter but not the granularity and base period is equivalent to returning to a state that never existed). A rollback MUST NOT change the underlying data itself; when the data has changed in the interim, what is restored is the condition, not the value at that time, and this MUST be knowable — presenting an old condition alongside new data without explanation would lead the reader to believe they are seeing the chart as it was at that time. The boundaries of the rollback capability (how many steps back are possible, whether it persists across sessions, whether it is lost after the page is closed) MUST be declared. When a restore fails, the currently valid state MUST be preserved, the unrestored portion explained, and a retry or return entry provided; a success message must not be used to mask a partial restore.

Boundary conditionsthis rule does not require unlimited-step rollback, nor cross-device restoration. A product that does not change any view condition may simply record "not applicable."

Design application"stepping back" in analysis has a different mental model from undo in document editing: what the reader wants to return to is a recognizable analytical state, not the previous click. Making rollback points into named states ("return to before drilling down") is closer to actual usage than step-by-step undo.

Verification examples

• User side: after applying six operations in succession, request a return to the third step and check whether all conditions return to that combination.
• Implementation side: update the underlying data between two visits and check whether restoring the historical state discloses that the data has changed.

CounterexamplesUnder-delivery — the browser's back button refreshes the entire analysis page back to its initial state, zeroing out half an hour of exploration; over-delivery — every step requires the user to name and save before it can be rolled back to, breaking exploration into a string of save actions.

Basis and referencesfor the presentation and rollback forms of analytical history, see R17.

VZ5-3An export carries the conditions under which it holdsMUST¶

In one sentence: Once an exported chart leaves the product, its conditions must travel with it.

Applies toproducts that provide image export, PDF export, data export, report generation, or screenshot-sharing capability.

Rulean exported graphic or dataset MUST carry the conditions under which it holds, covering at minimum: the data time point and refresh status (VZ2-1), all currently effective conditions (VZ4-1), the aggregation granularity and method (VZ2-4), the comparison baseline (VZ4-5), and the time point at which the export occurred. An image-type export cannot carry interactive explanation, so these conditions MUST be rendered into the image itself or delivered together with it, and must not rely on "you can see it once you're back in the product." A data-type export (CSV, a table file) MUST carry the conditions equally, and exporting only the numeric columns while discarding provenance and conditions is forbidden. This rule applies equally to the artifact of a screenshot or copy-to-clipboard capability the product provides — this is the category of artifact most often left out of the export process, and also the one most often forwarded. When an export contains an automatically generated graphic or interpretation, its generation source MUST be retained, and the interpretation MUST be distinguished from the raw statistical result.

Rulean export MUST be bound to the submitted conditions and the corresponding data snapshot, retaining the unit, provenance, missing and suppression status, sampling or downsampling notes, and any uncertainty that affects reading. When interface conditions change during the export process, two sets of conditions and values must not be mixed; permission MUST be re-checked. When the currently visible old result cannot be exported, the product should wait for the new result or explicitly provide a separate artifact — quietly swapping the numbers is forbidden.

Boundary conditionsthis rule does not require embedding a complete provenance document into every exported chart; what is required is that the conditions themselves travel with the chart — provenance detail can be carried as a resolvable reference (a fixed link to the corresponding definition, a provenance identifier). An image produced by the user's own system screenshot tool is outside the product's control, and this rule does not judge it noncompliant on that basis, but the product should make sure the chart already carries the key conditions on its face (see VZ4-1) to reduce this risk.

Design applicationrendering the structured description of "the current view's conditions" into the chart's footer is a second use of the same data, not a separately written export logic. The simplest way to judge whether this rule is implemented: send the exported PNG to someone who has never opened the product, and ask whether they can state what scope of data this chart is calculating.

Verification examples

• User side: hand the exported chart to someone who did not take part in the analysis and ask them to restate the data time point and effective conditions.
• Implementation side: for every export format and every screenshot path, check whether the condition fields are written into the artifact.

CounterexamplesUnder-delivery — an analyst screenshots a year-over-year chart into a group chat, and the chart shows only a line and a "+30%" with no one knowing which year the base period is or which channels were filtered; over-delivery — every exported chart is accompanied by three pages of appendix underneath, which gets cropped off in actual use.

VZ5-4A shared view is consistent with its conditionsMUST¶

In one sentence: What the recipient opens must either be the same chart, or be explicitly told it is not.

Applies toproducts that provide link sharing, view sharing, subscription pushes, or collaborative viewing capability.

Rulewhen a view is shared, the conditions the recipient sees on opening it MUST be consistent with the conditions in effect when the sharer shared it, or any difference MUST be explicitly disclosed. The following three kinds of difference MUST be handled rather than occurring silently: the recipient's data permission differs, resulting in a different data scope (it MUST be made knowable that "the scope you see differs from the sharer's," with the specific difference handled per the permission rules); what is shared is "a link to a live view" rather than "a snapshot at that time," so the data has since updated (the nature of the two MUST be distinguishable, and the data time point made visible); the recipient's personal default settings (default time range, default filter, time zone, currency, language) override the shared conditions (letting a personal default silently override a shared condition is forbidden). A share link MUST resolve to the complete view conditions, and must not carry only a page address while discarding the conditions.

Boundary conditionsthis rule does not require every share to be a frozen snapshot, nor does it require disclosing to the recipient content they have no right to view. When the sharer and recipient have the same permission, and what is shared is a live view already declared as such, data updating over time does not constitute a violation.

Design applicationmake "sharing a snapshot" and "sharing a live view" two semantically distinct actions rather than one link with two behaviors — the two are used completely differently in discussion: one says "this is what I'm seeing," the other says "go check how it looks now." Situations where a personal default such as time zone or currency overrides the shared condition are the most common point where cross-region teams' numbers stop reconciling.

Verification examples

• User side: open the same share link with two accounts that have different data permissions, and compare what each sees and what notices they receive.
• Implementation side: set the recipient account's default time range to a value different from the shared condition, and check which one takes effect after opening.

CounterexamplesUnder-delivery — a dashboard link is sent to a colleague whose permission covers only one region, and the numbers they see are half as large with nothing on the page saying so, so the two of them report different numbers at a meeting; over-delivery — every time the share link is opened, a complete condition-difference report pops up that must be confirmed item by item before the chart can be seen.

VZ5-5Annotations and conclusions are bound to the conditions under which they holdSHOULD¶

In one sentence: The statement "grew 30%" must stay bound to the set of conditions under which it holds.

Applies toproducts that allow annotations, labels, or comments to be added on a view, or that have the system generate conclusion copy, insight summaries, or alert explanations.

Rulea conclusive statement written on a chart should be bound to the conditions under which it holds, so that the reader can determine under which set of conditions that statement was made. When the conditions subsequently change, letting the original annotation continue to be presented as unconditionally true under the new conditions is forbidden — an annotation should be invalidated along with the condition it is bound to, marked as possibly no longer applicable, or have its original condition made queryable. This rule applies equally to system-auto-generated conclusion copy, which should also make the data scope and time point it is based on obtainable. When an annotation points to a specific mark (a certain peak, a certain interval) and underlying data changes such that mark no longer exists, the annotation's dangling status should be made knowable; silently dropping it, and silently re-hanging it onto a different mark, are both forbidden. An interpretation given by the system MUST be distinguishable from the data itself, and the data scope and time point the interpretation is based on must be queryable.

Boundary conditionsthis rule does not require every annotation to carry a complete condition list; resolvability suffices. Collaborative comments unrelated to the data ("let's discuss this next week") are not subject to this rule's requirement for condition binding.

Design applicationmake an annotation an object hung on "condition + mark" rather than a floating layer hung on coordinates. Annotations on a dashboard written six months ago, whose conditions have long since changed, are more misleading than no annotation at all — they look like they are explaining the current chart.

Verification examples

• User side: after changing the filter condition, check how the old annotation is presented, and ask the reader to judge whether it still applies.
• Implementation side: delete the data row an annotation points to, and check whether the annotation is marked invalid or re-hung onto an adjacent mark.

CounterexamplesUnder-delivery — a chart reads "November's peak came from the Double Eleven campaign," and after switching to "organic traffic only" this sentence is still in the same place while that peak has disappeared; over-delivery — every annotation is forced to carry a complete condition snapshot, making the annotation area longer than the chart, and no one writes annotations anymore.

Basis and referencesfor analytical-process retention and result interpretation, see R16, R17.

VZ5-6A change in basis that invalidates an existing artifact is disclosedMUST¶

In one sentence: When the underlying data is revised, a chart already sent out cannot pretend nothing happened.

Applies tosituations where underlying data may be revised, restated, backfilled, or recalculated under a new provenance, and the product has already produced outward-facing artifacts (exports, share links, subscription pushes, published reports).

Rulewhen a change in underlying data or provenance means the conclusion presented by an existing artifact no longer holds, the affected artifacts MUST be made identifiable, and their known recipients MUST be notified. The notification content MUST cover at minimum: the nature of the change (a data revision, a provenance change, a source restatement), the affected time range and metrics, and where the updated result can be obtained. Silently recalculating a published value without leaving a trace of the revision is forbidden (see also VZ2-3). When a product cannot track an artifact's recipients, this limitation MUST be made knowable, and at least the affected views within the product itself MUST be marked; taking no action at all on the grounds that recipients cannot be tracked is forbidden. Subscription pushes and scheduled reports MUST be able to issue a correction for a period already sent out.

Boundary conditionsthis rule does not require tracking screenshots and reposts that have left the product, nor does it require notification for a technical change that does not affect the conclusion (a backend storage adjustment, a rendering optimization). When a change does not alter any presented value, "not applicable" may simply be recorded. The criterion for "affects the conclusion" is declared and recorded by the product; these guidelines give no universal threshold.

Design applicationthis rule pairs with VZ5-3: only because an export carries its conditions is it possible to work backward and judge which artifacts were affected. Marking "data has been revised" only inside the product is not enough — the chart that has already gone out will not come back on its own to read the notice.

Verification examples

• User side: issue a revision to the data underlying an already-sent subscription report, and check whether the recipient receives a correction.
• Implementation side: inject a historical data backfill and check whether the system can list the affected published artifacts.

CounterexamplesUnder-delivery — a week after a monthly report goes out, the data is backfilled and the backend numbers change, while the old report still sitting in inboxes keeps being cited; over-delivery — every minor change to any data triggers a mass correction email to every historical recipient, and recipients start blanket-blocking the sender.

Basis and referencesfor analytical-process retention and result interpretation, see R16, R17.

3.6 VZ6 Data is perceivable and reachable¶

A chart is a path to a dataset, not the only path. Someone who cannot see the red-green difference, someone using a screen reader, someone who can only use a keyboard, someone looking at their phone in bright sunlight, someone who prints the chart in black and white — what they need to get is not a description of the chart, but the facts the chart carries. This principle governs whether these paths exist, whether they are equivalent, and whether they stay in sync with the primary path. This principle covers equivalent access to data, a floor for readability, and reachability of analytical operations.

VZ6-1Color is not the sole encoding channelMUST¶

In one sentence: Distinguishing two lines cannot rely on red versus green alone.

Applies toviews that use color to distinguish category, state, or represent quantity.

Ruleusing color as the sole visual channel to distinguish category or express state is forbidden. A category the reader must distinguish MUST be carried simultaneously by at least one non-color channel: position, shape, line style, fill texture, direct labeling, size, or grouping. Colors representing state and alerts (red for anomaly, green for on-target) MUST have a non-color expression as well (an icon, text, a marker, position). A categorical palette should adopt a scheme that remains distinguishable under common types of color-vision deficiency, and the source of the scheme used should be recorded; the orderedness of a continuous color scale is covered separately in VZ1-6. Labeling category names directly next to the marks satisfies this rule while also reducing the burden of looking things up in a legend, and should be preferred over legend-dependent coloring when the category count is small. When the number of categories exceeds the number of distinguishable colors, the encoding strategy MUST be changed (facets, direct labeling, grouping); continuing to add similar colors is forbidden.

Boundary conditionsthis rule does not forbid using color, nor does it require every chart to be readable in grayscale — what it requires is a channel besides color carrying the same distinction. The color mapping of a continuous quantity is itself handled under VZ1-6, and its distinguishability requirement is backstopped by numeric readability (VZ6-4) and the equivalent path (VZ6-2). Contrast and hit areas are verified under VZ6-6.

Design applicationconverting the chart to grayscale and looking at it once is the cheapest self-check. Writing the series name directly at the end of a line in a line chart is less work and more robust than a legend; a scatter plot combining shape with color still works under the two most common failure scenarios of printing and projection.

Verification examples

• User side: render the same chart in grayscale and ask the reader to complete the reading task supported by this chart's declared redundant path; this item does not require every chart to complete all tasks in grayscale, nor does it override the exceptions listed in this rule's boundary conditions.
• Implementation side: inventory every color assignment and check whether any distinction is carried by color alone with no second channel.

CounterexamplesUnder-delivery — a profit-and-loss table marks rise and fall with red and green alone, with no plus/minus sign and no arrow, so a reader with red-green color-vision deficiency reads two groups of identical numbers; over-delivery — every line is given color, line style, point shape, texture, and an endpoint label all at once, and when five lines crowd together the visual noise is so high that no one can read the trend.

Basis and referencesfor equivalent access to complex graphics and data tables, see R19, R20; for the contrast of color and necessary graphical parts, see R23.

VZ6-2A graphic has an equivalent data-access pathMUST¶

In one sentence: Someone who cannot read the chart must have another path to the same data.

Applies toviews that present data.

Ruleevery view that carries data MUST have an equivalent path that does not depend on reading the graphic, letting the reader obtain the data the view presents. The test for equivalence is whether the task the chart claims to support can be completed, not whether the chart's appearance can be reproduced: this can be an accessible data table, a structured text summary plus a list of values, or a sequentially traversable series of values. The equivalent path MUST present the same data under the same set of conditions as the primary view, and MUST update in sync with the primary view; when the primary view changes due to linking or filtering, the equivalent path MUST change accordingly. Using "the data can be exported" as the sole equivalent path is forbidden — an export is a one-off action and does not constitute equivalent access to the current view. The entry to the equivalent path MUST be discoverable, and must not require completing a visual reading first in order to reach it. A data table MUST have identifiable headers and data association, and operation entries MUST have a name, role, and state; keyboard and non-drag paths are verified under VZ6-7.

Boundary conditionsthis rule does not require providing a data path for purely decorative graphics, nor does it require the equivalent path to reproduce the graphic's visual structure. A view with an extremely large amount of data (a scatter plot with hundreds of thousands of points) is not required to be readable point by point, but MUST provide the information needed for the reading task that view claims to support (a distribution summary, aggregate values, a queryable subset); when a summary is used as a substitute, its coverage MUST be declared.

Design applicationthe place where an equivalent path most easily fails is "synchronization": the table is rendered from the initial data, the chart changes as filtering happens, and the table does not. Wiring both to the same query result is more reliable than aligning them after the fact. When the data volume is large, rather than providing an unreadably long table, provide the answer to the question this chart is meant to answer.

Verification examples

• User side: without using the visual presentation, complete the task this view claims to support using only the equivalent path.
• Implementation side: apply a filter and check whether the content of the equivalent path changes accordingly.

CounterexamplesUnder-delivery — a complex dashboard is entirely canvas-rendered, and a screen reader reads only the words "chart"; over-delivery — a mini trend chart with three points generates a thousand-row data table containing every raw detail, and the equivalent path itself becomes a burden.

Basis and referencesfor equivalent access to complex graphics and data tables, see R19, R20; for the contrast of color and necessary graphical parts, see R23.

VZ6-3An alternative description states the data, not the appearanceMUST¶

In one sentence: Don't read out "a blue line chart" — say where the line goes.

Applies toproducts that provide a text alternative description, summary, or spoken description for a graphic.

Rulea graphic's alternative description MUST state the data and the information the chart is meant to convey, not the graphic's appearance. It MUST cover at minimum: the quantity the chart represents and its unit, the scope and time point covered, and the key facts needed for the reading task this chart claims to support (trend direction and magnitude, extreme values and their location, relationships among groups, anomalous points). Using a description of the chart type, color, or style as the alternative description is forbidden ("a line chart containing five colored curves" does not satisfy this rule). The alternative description MUST present the same data under the same set of conditions as the chart, and MUST update when the conditions change. A conclusive statement within the alternative description MUST be distinguishable from the data itself; when auto-generated by the system, its generation source MUST be retained. An alternative description must not, for the sake of brevity, omit the parts of the time point, provenance, and uncertainty information required by VZ2 and VZ3 that affect reading.

Boundary conditionsthis rule does not require the alternative description to enumerate every data point exhaustively — the complete values are carried by the equivalent path in VZ6-2; what this rule requires is the information this chart conveys. This rule does not apply to purely decorative graphics.

Design applicationthe way to write an alternative description is to first answer "what is this chart meant to let people know," then write down the answer. An auto-generated description easily degenerates into a recitation of appearance, because appearance is the only thing the rendering layer knows for certain; wiring the chart specification's "declared reading task" field into the generation process pulls the description back from shape to data.

Verification examples

• User side: read aloud only the alternative description, ask the listener to restate the chart's main facts, and compare against the restatement of someone looking at the chart.
• Implementation side: change the data so the trend reverses, and check whether the alternative description changes accordingly.

CounterexamplesUnder-delivery — an image's alt text is written as "quarterly-sales-chart.png"; over-delivery — a four-hundred-word description reading out every value point by point, so that by the thirtieth number the listener has already lost the overall picture.

Basis and referencesfor equivalent access to complex graphics and data tables, see R19, R20; for the contrast of color and necessary graphical parts, see R23.

VZ6-4Reading and comparing values does not depend on hover or fine pointingMUST¶

In one sentence: A specific value must not be hidden only in the instant the mouse happens to rest there.

Applies toviews that provide value reading and detail through hover tooltips, pointer following, brushing, or interaction requiring precise positioning.

Ruleany information on a chart obtainable only through hover or fine pointing MUST simultaneously have another access path that does not depend on hover or fine pointing. This applies to: value reading (a specific number in a tooltip), the encoding description (VZ1-1), provenance and definitions (VZ2-2), the meaning of an uncertainty representation (VZ3-2), and category labels. Touch devices have no hover state, so in a product that declares touch support, hover does not constitute a usable path for any information. Selecting dense marks (small scatter points, narrow bars, small regions on a map) must not require pointing precision beyond the range the product declares support for. When a low-precision channel such as area, angle, or color carries a quantity that requires a quantitative reading, the numeric-reading path this rule requires is mandatory (see VZ1-7, VZ1-4). The content of detail that appears on hover or selection MUST match the content provided by the equivalent path. Operable-target and focus requirements are covered in VZ6-6; keyboard and non-drag operation are covered in VZ6-7.

Boundary conditionsthis rule does not forbid using hover tooltips, nor does it require every value to be permanently displayed; what it requires is that hover not be the sole path. A purely visual-enhancement effect (a hover highlight that carries no additional information) is not subject to this rule.

Design applicationkeyboard traversal of data points, fixed detail display after click-select, toggleable value labels, and the VZ6-2 data table are all usable second paths; of these, a data table is usually the least effort, because it simultaneously satisfies VZ6-2. Mobile products especially need to check hover logic ported over from desktop — it is often changed into a long-press, and a long-press is neither discoverable nor free of conflict with system gestures.

Verification examples

• User side: unplug the mouse and use only the keyboard to read the specific value of any data point on the chart.
• Implementation side: inventory every piece of information that exists only in a hover state, and check item by item whether it has a second path.

CounterexamplesUnder-delivery — a scatter plot with 200 points, where each point's label appears only when the mouse rests precisely on the 4-pixel dot, is completely unusable on touch; over-delivery — all data labels are permanently displayed on the chart, and 200 numbers overlap each other, drowning the graphical structure in text.

Basis and referencesfor equivalent access to complex graphics and data tables, see R19, R20; for the contrast of color and necessary graphical parts, see R23.

VZ6-5Analytical conditions are equally visible and operable on the equivalent pathMUST¶

In one sentence: Filter state must not be shown only as a few colored capsules.

Applies toproducts that provide analytical-condition operation capability and must also satisfy the VZ6-2 equivalent-path requirement.

Rulecurrent view conditions that VZ4 requires to be visible MUST be equally obtainable on the equivalent path; conditions that VZ4 requires to be removable MUST be equally removable on the equivalent path. An equivalent path where "you can see the numbers but don't know they've been filtered" is forbidden — an accessible data table with no condition statement is more likely to lead to a wrong conclusion than no equivalent path at all. When a condition changes (by the user's own action, by linking, by an automatic system action), that change MUST be perceptible on the equivalent path; the announcement should merge consecutive intermediate changes, retain a result summary and failure information after submission, and must not go completely silent due to frequent changes. The scope of a linked action (VZ4-3) MUST be equally determinable on the equivalent path. The analytical path and rollback capability (VZ5-1, VZ5-2) should be usable on the equivalent path.

Boundary conditionsthis rule does not require the equivalent path to reproduce the condition area's visual form, nor does it require every condition change to force an announcement of all conditions. A product that provides no condition-operation capability at all may simply record "not applicable."

Design applicationuse the structured description of "the current view's conditions" simultaneously as the content source for the equivalent path — this is where VZ4-1, VZ5-3, and this rule share the same mechanism. The condition area is typically the last part of a visualization product to be brought into accessibility remediation, because it looks like "something outside the chart," even though it is exactly what determines what the numbers in the chart are.

Verification examples

• User side: using only the equivalent path, determine which conditions are currently applied to the data, and remove one of them.
• Implementation side: trigger a condition change caused by linking, and check whether the content and status notice on the equivalent path update accordingly.

CounterexamplesUnder-delivery — an accessible data table is complete and accurate, but the reader has no way to know it only contains East China, because the region filter is expressed only as a colored capsule; over-delivery — every single filter change announces all seventeen conditions, and the reader cannot complete continuous operation.

Basis and referencesfor equivalent access to complex graphics and data tables, see R19, R20; for the contrast of color and necessary graphical parts, see R23.

VZ6-6Readability and operable targets have a verifiable floorMUST¶

In one sentence: Necessary graphics must be clearly readable, operable targets must be hittable, focus must be visible.

Applies tochart text, necessary data graphics, legend controls, filter controls, and interactive targets.

Rulea product using a Web interface MUST check the following requirements against the applicable WCAG success criteria, and record the measured object, the actual value, and any applicable exception. Ordinary text contrast is at least 4.5:1, large text at least 3:1; large text is judged by the standard's definition, not by a component's name. A graphical part necessary for identifying a control's state or understanding content must be at least 3:1 against its actual adjacent color. A pointer target is at least 24 × 24 CSS px, or satisfies a specific exception for spacing, equivalent target, inline, user-agent-controlled, or essential presentation. Keyboard focus MUST be visible and must not be completely obscured by author-created content. A blanket exemption on the grounds of "too many chart points" is forbidden.

Boundary conditionsa data point's visible size and its hit area may differ; enlarging the hit area must not change the data encoding or create indeterminate overlapping targets. Provide an equivalent control in a list or data table where necessary. The 3:1 requirement does not require indiscriminate pairwise comparison of all series; a region whose reading depends on an adjacent boundary must have that boundary checked, and separated, labeled lines are checked against their actual background. Recording a deviation and its alternative measure does not amount to a claim of standard conformance. A non-Web product MUST declare the applicable platform requirements and unit of measurement, and must not treat a CSS px directly as a physical pixel.

Rulefor a user with a reduced-motion preference, a static or reduced transition MUST be provided; an auto-update or animation MUST NOT continuously interrupt reading, and a pause or manual-update entry MUST be provided.

Design applicationverify body text, thin lines, selection strokes, and focus separately; also bring dark themes, forced-colors mode, and export results into the check.

Verification examples

• User side: identify data, selection state, and focus under zoom, forced colors, and keyboard operation; use an alternative list to select dense points on touch.
• Implementation side: check the actual adjacent color, font size, hit area, occlusion, and exception evidence; check whether enlarging the hit area still allows a target to be uniquely selected.

CounterexamplesUnder-delivery — a key series is encoded with a light-gray thin line, and focus is covered by a floating layer; over-delivery — every scatter point is drawn as a 24 px circle, covering up the data distribution.

Basis and referencesR23, R32. Standard thresholds and task distinguishability must be accepted separately.

VZ6-7Analytical actions have keyboard and non-drag pathsMUST¶

In one sentence: Being able to read the numbers must come with being able to select, filter, compare, and exit.

Applies toproducts that provide brushing, zoom, pan, drill-down, legend operation, data detail, or real-time update.

Ruleanalytical functions MUST have a keyboard path; a drag operation MUST have an additional single-pointer, non-drag path, judged against the standard exceptions for essential dragging or unmodified user-agent functions. Brushing may use start/end value input, and pan and zoom may use buttons — a keyboard alone must not be the only substitute for dragging. Focus, hover, selection, and filtering MUST be distinguished; a focus move MUST NOT implicitly submit a filter. A detail overlay MUST be closable, and after closing, focus MUST return to a sensible position. Navigation of dense points MUST provide grouping, search, paging, or an equivalent table, and must not require tabbing through every mark one by one. A result update MUST NOT steal focus; when the focused object disappears, focus MUST be moved to an explainable position and this disclosed.

Boundary conditionsthis rule does not require creating a tab stop for every point, nor does it mandate complex grid semantics. Shrinking the container may adjust the layout, but must not silently drop key conditions, uncertainty, or operation entries.

Design applicationprovide start/end input for brushing, buttons for pan and zoom, and a searchable table for dense points; use grouped navigation within a chart, and return to the original object or the corresponding group after exiting a detail view.

Verification examples

• User side: complete range selection, drill-down, clearing, and rollback without a mouse; complete the same actions with a single pointer without dragging, and return to the original position.
• Implementation side: check for keyboard-shortcut conflicts, focus restoration, overlay closing, focus binding after a live re-sort, and static paths under a reduced-motion preference.

CounterexamplesUnder-delivery — filtering is possible only through drag-selection; after the chart refreshes, focus jumps to the top of the page; over-delivery — a tab entry is created one by one for a hundred thousand points, making it impossible to leave the chart.

Basis and referencesR32; the implementation requirements for dense navigation and stable focus are derived from task reachability.

4. Terms and definitions¶

This chapter defines the core objects used for reading, implementation, and acceptance.

Appendix A: Fault-injection verification checklist and classification test¶

This checklist is used to verify whether the clauses actually take effect; it adds no new obligation. Inject item by item and record the system's actual behavior; recording "not applicable" is a valid result, recording "not tested" is not.

A.1 Encoding

A.2 Provenance

A.3 Uncertainty

A.4 Analytical conditions

A.5 Process and artifacts

A.6 Perception and reachability

A.7 Coexisting with an agent

A.8 Classification test

Used to verify whether the division in Chapter 1 holds: take 10 to 15 concrete requirements (either from these guidelines' clauses or from real review comments), and have at least three reviewers who did not take part in drafting independently judge their principle assignment. When assignment disagreement concentrates between two particular principles, that means those two principles' regulated objects have not been separated — at that point the principles should be adjusted, rather than adding an intermediate layer or explanation. The two places already known to need focused testing are stated explicitly in Chapter 1 (VZ1 and VZ2, VZ4 and VZ5). The number of reviewers and the disagreement threshold are an internal check method these guidelines suggest, not a standard validated by the literature.

A.9 Supplementary failure scenarios

Appendix B: Evidentiary boundaries and source types¶

B.1 The criterion for normative terms

The sole basis for marking something MUST is: without it, some promise made to the reader would fail in a foreseeable situation. The following three types of evidence provide different kinds of support; they are not three independent mandatory sources — an implementation reference by itself is not sufficient to decide a MUST marking —

Among the seven rules marked SHOULD (VZ1-6, VZ1-7, VZ2-6, VZ3-5, VZ3-6, VZ4-6, VZ5-5), most are a matter of trade-off rather than a bottom line: a deviation may have a legitimate reason, but it must leave a trace and accept the same verification. Among these, VZ1-6 permits a domain-convention color scale, VZ4-6 permits an "other" grouping, and VZ3-5 permits a rough ranking already declared as not a basis for conclusions — the exception scope at these three points is the one most easily stretched in use. The forbidden-level clauses contained within these rules (see 2.2) are not downgraded merely because the rule they sit in is SHOULD.

B.2 The three places where this specification's evidence is weakest

Stated plainly, without hiding behind normative tone:

1. VZ1-7's channel-precision ordering comes from controlled experiments under specific tasks, and cannot be used as a universal ranking. Both the classic experiment and its crowdsourced replication derived precision differences under controlled comparison tasks, but they do not cover every reading task, every data scale, or every reader population; reading it as "position is always superior to area" is an out-of-scope use of the evidence. These guidelines therefore write it only as a basis for choice and a recording requirement, without giving a substitution checklist — this is also the rule in these guidelines most easily mis-cited.
2. VZ3-3's small-sample threshold has no universal value verifiable by these guidelines. Written presentation thresholds exist within public statistical systems, but those values are set for a specific statistical system and purpose, and cannot be transplanted as a universal threshold. These guidelines only require that the threshold be explicitly defined, have a basis, and take effect on every drill-down path — no value is given, which makes the strictness of this rule depend on whatever number the product itself sets.
3. The empirical support for the whole VZ5 group is weaker than for VZ1 and VZ3. The two matters of analytical-process retention and an artifact carrying its conditions mostly appear in research as system designs and case studies; this search found no cross-product controlled study proving that "an artifact that carries its conditions generally reduces misreading." The strength of this group of clauses comes from consequence analysis (a chart gets forwarded, its context does not), not from experimental evidence; VZ5-6's "affects the conclusion" criterion is self-declared by the product, making it the point in this group most likely to be circumvented.

B.3 What these guidelines do not do

They do not judge the correctness of a statistical method, do not provide a manual for choosing chart types, do not provide a lookup table for "which data uses which chart," do not provide color schemes or brand themes, do not provide chart-library APIs or mark implementations, do not make accessibility conformance determinations, do not perform data governance or data-quality assessment, and do not make privacy-compliance determinations. These are decisions for the product, the design system, statistics, and dedicated assessments; these guidelines only require that these decisions be made, be verifiable, and specify which values are not permitted.

B.4 Sources

The complete source comparison, verification status, and search record are in reference.md. A clause in these guidelines does not hold merely because some tool has done it that way; a tool's practice is evidence that "this kind of mechanism is feasible in a real product," not a basis for "it should be required this way." Where multiple public guidelines are inconsistent with each other, these guidelines do not rank them by merit, and take only the behavioral nature they commonly support.

---

Implementation acceptance scenarios¶

The scenarios below turn existing clauses into reviewable acceptance inputs, without setting any additional general performance threshold. Select them according to the product's applicable capabilities, and supplement with real devices, users, input sequences, and evidence; record the reason when not applicable, and an item not executed must not be recorded as passed.

Each scenario checks the configuration's effective value, the execution record, and a user-understandable result separately. Retain the version, target, event time point, failure scope, and recovery result; an unknown external result must not be filled in as either success or failure.