Accessibility: more legible axis tick labels and other textual chart elements

[monfera]

Is your feature request related to a problem? Please describe. Increase font legibility and disambiguation in Charts examples and Kibana, by default. Problems:

• too small font size for axis tick labels in practice (in Kibana and in Charts examples)
• zeros are not crossed; default fonts (in Kibana and in Charts examples) with their default settings are not as suitable for data visualization in our technical domain
• not enough contrast with the default grey, and I haven't encountered justification for NOT upping axis tick label legibility via maximum contrast

Describe the solution you'd like A clear and concise description of what you want to happen.

• larger fonts as defaults, eg. size 11 instead of size 10
• black font (on white background) for axis tick labels instead of the current medium grey
• disambiguated and accessibility driven font choice

Describe alternatives you've considered

Letting Kibana decide on the font anyway. While the capability exists, the themes specify

• a bit too small font esp. for axis tick labels
• WAY too faint fonts for axis tick labels—it should be much closer to black (on light background) than is now, even if the user hasn't set high contrast preferences or accessibility controls

Canvas2d can't currently use most font options in this space while there's work in progress. So, we have these non-exclusive options:

• wait for the Canvas2d standard to grow into modern a11y and other font config needs, and for the main browsers to adopt these (you can help by starring the linked gh issues and following the conversation)
• switch to font rendering with HTML instead of, or as a complement to Canvas2d, permitting more font options
• advocate for fonts which treat character face disambiguation as a key objective even by default; with our typically high technical usage involving lots of alphanumeric codes in ES, it should be the default

Personally I think we should do all these, and using more legible fonts out of the box is the smallest, quickest change in elastic-charts so our examples may play with font cc @cchaos @ghudgins

We should also drive certain font face and other features such as disambiguation and color from standard notations for user preferences, eg. prefers-contrast: more leading to crispier, top contrast, more legible text. Based on earlier chats with Design, a mix of CSS and JavaScript is needed for this.

Additional context The below started as a response to @nickofthyme's question on why putting the Hyperlegible font in chart our examples:

Being able to bring in other font types need not be for specificity. For example, Canvas users are more likely style their charts beyond the usual fonts and it's neat to have font flexibility, test drive odd sized fonts etc.

[Image 1: showing an artistic Kibana Canvas dashboard of consumption in a café, with highly stylized, chalk-like font for fun presentation, where readability is unimportant but style is)

Also, even on account of simple dataviz design, some fonts are better than others, so it's useful for us to be able to switch among fonts. In dataviz, font legibility and disambiguation of character shapes is more important than in generic UI design: space is at a premium, and often, there's a bunch of text is in a row that needs to fit (axis tick labels); Kibana tick label font sizes are pretty small.

Elasticsearch data is usually a huge pool of technical names, with numbers, zeros and special characters in random order, so the distinction between 0 and O is way more important than on WIMP GUI texts.

This font was made with the involvement of the Braille Institute and highlighted , expressly optimized for distinguishability esp. among otherwise ambiguous shapes, even if someone's vision is blurred:

[Image 2: the Atkinson Hyperlegible font sheet that shows the effect of disambiguated font face design even with blurred vision]

@cchaos rightly pointed out that even the current Kibana fonts, whose baseline has no emphasis on disambiguation, can be configured for it, and other font options such as tabular fonts, essential for vertically aligned numbers like Y axis tick labels, are also possible.

However @markov00 pointed to standards issues which make these font configuration options unavailable to Canvas2d. Work is ongoing. See more in the #datavis channel, starting with @ghudgins's message on Sept 1.

While standards and browsers evolve, and we may want to consider switching to HTML text rendering for the font options, it's good if we start to evolve our fonts muscles beyond just assuming the default fonts in our examples.

Also, besides legibility, it's a font that has character, and I think it looks better on, and is a better match for a technical or other quantitative focused dashboard than the baseline fonts.

Hyperlegible has weaknesses too, for example, it's not a parametric font with respect to font weight, and the set of available font weights is poor for dataviz (only normal and bold). Dataviz benefits from a fine raster of font weights, though overly fine (eg. weight of 100 or 200 in a font size of 10pt or so) or too heavy fonts would interfere with the goals of Hyperlegible anyway.

Kibana Cross Issues Add any Kibana related issues/feature requests here.

Checklist

Delete any items that are not applicable to this feature request.

• [ ] this request is checked against already exist requests
• [ ] every related Kibana issue is listed under Kibana Cross Issues list
• [ ] kibana cross issue tag is associated to the issue if any kibana cross issue is present

[markov00]

I want to add the need to be aligned with the browser preferences for Minimum font size and font-size adjustment.