add more info to building materials suggestion section (#29)

Author: frankelavsky

source/index.md

@@ -398,7 +398,7 @@ More care should also be taken for describing what various things and explaining
 
 The next most important thing, after locking in text-related accessibility, is to use the correct building materials.
 
-As already hinted, `<canvas>` can have some limitations for accessibility. It's great for high-performance rendering, but that performance is directly related to a lack of markup + DOM overhead that comes with more accessible materials, like HTML (or even SVG).
+As already hinted, `<canvas>` can have some limitations for accessibility. It's great for high-performance rendering, but that performance is directly related to a lack of markup + DOM overhead that comes with more accessible materials, like HTML (or even SVG). This problem is pervasive, especially among charting libraries (Vega-lite, Highcharts, etc) with some accessibility capabilities in `<svg>` that are lost if users decide to render in `<canvas>` for the performance benefits. Even `<svg>` has some limitations, due to asymmetrical adoption of ARIA standards, which is why some libraries like [Visa Chart Components](https://github.com/visa/visa-chart-components) renders an accessibility layer using pure HTML (which has high support and standardization) with `<svg>` under the hood. My project [Data Navigator](https://dig.cmu.edu/data-navigator/) takes this idea of separating the visual rendering layer from the accessible rendering layer, but generalizes to virtually any frontend ecosystem (while also [retaining high-performance](https://www.frank.computer/data-navigator/#discussion-1)). We've used it in open source work with [Adobe](https://github.com/adobe/react-spectrum-charts/pull/483), so it is something worth considering if Bokeh intends to continue rendering in `<canvas>`.
 
 As for virtually everything that is interactive, from annotations, tooltip-triggering elements, to the buttons in the plot tools, natively semantic HTML elements will be far better for accessibility than the elements that they currently are. As an example: a `<div>` isn't natively semantic at all, but a `<button>` is. Adding on-click event listeners to a div would make it listen to mouse events, but keyboard-driven assistive technologies can't reach those elements natively, like they do with a button. The general philosophy here in accessibility communities online is that if a native element can do what you're trying to do, you should use that element.