[Accessibility improvement] Add ability to explicitly set treeitems number and position

[Karkhutvy]

Aria-posinset and aria-setsize attributes is used by screen readers to define and announce tree element position and elements number. By default, these attributes are computed by the browser. And ARIA 1.1 says for them “If all items in a set are present in the document structure, it is not necessary to set this property, as the user agent can automatically calculate the set size and position for each item”. But different browsers compute these properties differently. And while I was testing jsTree for different combinations of screen readers and browsers I found several issues. The problem with duplicated values for Google Chrome already fixed in https://github.com/vakata/jstree/pull/2441. But I still detect two problems:

1. Mozilla Firefox compute wrong element position if “li” element with role “none” or “presentation” have any label (title, aria-label or aria-labelledby). I approved from Firefox team that it is browser bug and they must decide how to fix this. But until it is fixed screen readers announce wrong elements position in jsTree.
2. Second problem is reproduced for Internet Explorer + NVDA. In this combination NVDA doesn’t read elements number and position in jsTree at all.

I created custom version of jsTree where aria-posinset and aria-setsize are calculated inside jsTree and explicitly set for tree items. For this version - described above problems were fixed. Different browsers and screen readers works more stable if we set these attributes explicitly. How about to add functionality to jsTree? We can make this optionally – for example create option “compute_elements_positions” and set default value to false. And if user wants to increase compatibility for more browsers and screen readers combination, he can turn on this option. If this functionality is acceptable for jsTree I can create pull request. And I also attached patch with possible implementation. 0001-Added-ability-to-explicitly-set-tree-elements-number.txt

[vakata]

@Karkhutvy once again - thank you for all you are doing to improve jstree's accessibility! A PR would be great - I will merge it right away.

[Karkhutvy]

Thank you @vakata. I'm glad to help this project. And one more question, when can we expect the release of a new version of jsTree?

[vakata]

Unfortunately I do not have a date - it has been hard to find time for feature development recently.

I meant to talk to you about the new v.4 - how do you feel about the current default renderer in regard to accessibility. It is a flat list of divs - an infinite scroller. My understanding of the tree spec is that it will not work with screen readers. Do you think something can be done, or should we simply include a hierarchial renderer (similar to v.3) and leave it to the developer to choose the renderer? The latter is simpler, but it promotes bad practices - most developers will probably go with the faster and lighter infinite scroller and break accessibility. The v.4 code is in an early stage (but works) in a branch in this repo.

Maybe we can discuss this here: https://github.com/vakata/jstree/issues/2449

[Karkhutvy]

Hi, @vakata, it would be perfect to use the infinite scroller and make it accessible. I checked renderer from v.4 from another branch. I suppose, it should be possible to make this tree accessible if we could implement required for tree keyboard interaction(maybe need to think how to correctrly implement it for home/end buttons and search by key), manually calculate tree size and elements position (it could be done with aria-posinset/aria-setsize) etc. So, with proper tree structure and aria-attributes screen reader should read and interract with the tree correctly. I will try to add some aria-atributes and keyboard interaction to test it with Jaws and NVDA. If you could explain your particular concerns about a11y for v.4 - I'll think about specific solutions for them. I'm not sure if there is perfect solution for this case but some basic accessability can be added. I need more testing to be more concrete.