Take letter-spacing and font-size into consideration while rendering ticks

[saghan]

This is an attempt to improve accessibility in recharts. According to Web Content Accessibility Guideline there should not be loss of content when letter-spacing is increased upto 0.12em. CartesianAxis component wasn't taking into consideration letter-spacing while calculating size of ticks. I am trying to fix it. (NOTE: All tests pass)
LineChart before fixing (with letter-spacing 0.5em):

LineChart after fixing:

[cscrosati]

This is clearly a good improvement since there is no more overlap, which is stated in the WCAG Understanding document as a failure.

[cscrosati]

Can you add tests to the PR to ensure the functionality doesn't regress?

[saghan]

Can you add tests to the PR to ensure the functionality doesn't regress?

Done.

[cscrosati]

I have another test suggestion:

FontSize/TextSpacing is X1/Y1, and the ticks are {a/b/c}
then when changing FontSize/TextSpacing to X2/Y2, ticks are now {a/c}

Something that confirms that applying a new computed style values does indeed discard or add the ticks as needed. Also independently change FontSize and TextSpacing to prove they independently are impacting the result.

[saghan]

I have another test suggestion:

FontSize/TextSpacing is X1/Y1, and the ticks are {a/b/c} then when changing FontSize/TextSpacing to X2/Y2, ticks are now {a/c}

Something that confirms that applying a new computed style values does indeed discard or add the ticks as needed. Also independently change FontSize and TextSpacing to prove they independently are impacting the result.

getComputedStyle does not work as expected with Karma. That's why the change works fine in a sample but not in test browser. So I have added a test to ensure that at least the states are picked correctly when getComputedStyle is stubbed.

[cscrosati]

@arcthur @xile611 This change was made to improve the accessibility of the axis overlapping ticks. This resolves concern with https://www.w3.org/WAI/WCAG22/Understanding/text-spacing.html requirements. Let us know if you have additional concerns with this proposed solution.

[cscrosati]

Note: this PR provides is supporting #2801

[jdom]

LGTM. Thanks for contributing this. We are running into some of these accessibility issues in our planning phase on whether to use the library for our project too.

[nmoinvaz]

It seems the calls to getElementsByClassName introduced in this PR broke IE 11 support. I didn't see any babel polyfill that would provide this function and the one polyfill that I did try didn't work. https://gist.github.com/eikes/2299607