Is there a step by step guide to making a Hype doc accessible for screen readers and keyboard navigation?
There's a chapter about Accessibility in A Book About Hype. That has a lot of useful information, but Accessibility could be a profession by itself, so the topic is even more advanced than what the book covers.
There's also this thread… Accessible Documents in Tumult Hype …but it looks like you've already been there.
1 Like
Thanks I’ve been to the one on the forum but will check out the other
I’m particularly interested in the tab order
There's also a bit of information in the hype documentation:
It doesn't go into too much depth with the tab order. The basic of it is that you would need to check tab index for each, and manually manage the indexes to what you want.
And then, test a lot 
.
1 Like
Thanks Johnathan
Ive been told apart from the keyboard nav and alt tags I have to put in h1 and h2 tags etc into the existing text throughout all the documents - is there an easy way to do that when I have used text objects throughout at different sizes?
1 Like
Probably adding <h1> tags directly is the wrong way to add this accessibility. Instead you should just be able to set the Role field in the Identity Inspector to that which would match the <h1> tags. In this case, using heading is probably what you'd want:
This sets the aria-role for the element. You can test this; it may be all you really need.
Otherwise I wouldn't say there's an "easy way" to specifically use those tags – I'd consider this being Hype arbitrarily allowing swapping the tag type from its default <div> to these, which cannot currently be done.
You can add these tags relatively painlessly via choosing 'Edit > Edit Element's Inner HTML' and then putting a <h1> in the beginning and </h1> at the end of this. The main issue is that these will probably affect your styling, so then you might need to restyle.
Restyling in this manner can fight against the app a little bit -- if you select all the text it will think you're trying to style the the element's div and not necessarily text inside these <h1> tags. So you may need to do partial selections to get the style right.
Thus I'd seriously try to go the Role route if that winds up working.
2 Likes
Yes I tried adding h1 etc tags to the inner html and it works but is time consuming so I’ll try the other method tomorrow.
Other than “heading” in that field what are the other options to differentiate between heading sizes and paragraph styles.
I also tried a widget visible top right
http://elearningproducts.com.au/temp/accessibility/1_introduction.html
I think what's important is to step back and really see the reason for accessibility. Try to imaging what trouble a user might have… such as mobility. That's one of the reasons for specifying a tab index, where even moving a mouse could be troublesome.
That's also why headings matter, because software can be used to help users navigate the page. Users can skip around the page based on the structure of headings. That why it's important to go in order. H1, H2, H3… that's not just for decoration.
However, that doesn't mean you need to add tab index to headings. That's kinda redundant. Personally, I like to reserve tab index for interactive elements or forms.
You have some navigational elements… like going to the next page. That part kinda works. I can tab to that button and then press space. The problem is that I'm being stopped by so many other elements before getting there.
Also, highlighting of tabbed elements might be a concern. I wasn't sure if the "Next Page" button was highlighted.
@jonathan is right — this needs testing.
As an example, I used WAVE…
There are accessibility issues. The language one is not too bad. That can be fixed by adding some HTML to the head of the document.
Contrast might be something to fix. It means the color of the background and the color of the text is too close to each other, which may make the text difficult for website visitors with vision problems.
Just in general though… it looks like a nice site. It seems fixable. You're facing common accessibility problems. However, I'm not sure why you're using Hype. I'm not seeing things like responsiveness or animation. Your page navigation by using Hype adds accessibility issues. Maybe static web pages would be better? 
If you want to stick with Hype, then you can improve the document by using ARIA tags to give the page some structure.
Actually, that's useful even if you're not using Hype. You can set regions, such as Main Content or Navigation. As an example, that 1 2 3 4 5 6 7 at the top right needs work.
3 Likes
Ah! See! It's not just me…
Avoid using the tabindex attribute in conjunction with non-interactive content to make something intended to be interactive focusable by keyboard input.
Thank you, this is quite an intense area. I have a zoom call with an accessibility expert on tuesday to get a better understanding.
Cool!
@Jonathan — It seems Hype can improve in this area. In addition the previously mentioned issue with document language, specifying “Page Regions” in a Hype document is not easy. At least, I'm not seeing an easy way to do it because it uses specific HTML tags.
That might be a nice feature for the next major version of Hype.
It looks like ARIA attributes can be managed with the “Additional HTML Attributes” Hype Pro feature, so that's nice. The “role” attribute is in the information tab too. But, perhaps this can be expanded to make Hype better for accessibility.
It's tough, because it depends on the content, but maybe even Accessibility checking could be part of Hype… contrast warnings, missing alt tags, page structure… might be very helpful.
1 Like
Not having seen how accessibility tools actually treat it, the Page Regions documentation does have a "Page Regions in HTML4 Using WAI-ARIA" section that does not use the HTML tags. Then this could be done with groups/IDs/Classes/Additional HTML Attributes (though IDs could be a problem if they are indeed required and you're doing a multi-scene/layout hype doc).
Agreed.
I think a report with suggestions makes sense. I wouldn't want to necessarily state things are 100% wrong on stuff where we don't have enough context.
1 Like
This has become increasing more important as I just lost a government contract due to inability to meet accessibility. They weren't expecting 100% as no one seems to reach that but they have a duty to show that there is a 'reasonable' attempt to have accessible resources.
Yikes, I'm sorry to hear that. Was it the heading issues specifically or other aspects that were the problem?
1 Like
It was relayed through a non accessiblity person who had notes saying it was page structure, h1, h2 tags and alt tags
Being able to tell Hype to use a custom tag instead of div could fix it. H1 etc. can also be added in inner HTML meanwhile. DIV does have the Divception problem adding also these container levels, breaking stacking context and bloating the HTML. That would also be a nice fix when this is touched in a future version.
1 Like
That's a shame, given there are workarounds. Perhaps at some level the issue is that Hype's DOM is generated on the fly, instead of being scannable HTML code?
I think Max is right. You should be able to specify the tag for an element. Making everything a div inherently makes Hype a problem for accessibility.
If I could say a group was a “nav”
and a text box was “h1”
then that reduces the need for tedious workarounds.
Having to manually add structure to a page with HTML code is… well… counterintuitive. People tend gravitate towards Hype because they don't want to code.
1 Like
I looked into the runtime … the function createDomElement already has the capability to render any kind of element. The element object contains the node type and is set by Hype (when building the DOM structure from the stored object in exported *_hype_generated_script.js). A possible approach would be to expose the node type in the interface? …
...
var createDomElement = function(scene, element, elementOid, classNames) {
// Allow setting node name/type by exposing the 'k' prop in Hype
var elementElement = document.createElement(element['k']);
...
1 Like
Yeah, it'd just be something in the Identity Inspector.
The accessibility reasons I'd say put including this over the top. The main reasons it wasn't added already were just that it can be quite a footgun, possibly break the editor environment, and adds UI complexity. (this is all pretty similar to class names, which were added)