Ambiera ForumDiscussions, Help and Support. |
|
|
|||||
|
I'm new to responsive web design but i'm loving it and RocketCake makes it that much easier to deal with. I'm building a website that absolutely needs to be accessible to screen readers and keyboard only controls. Was testing what I have built so far and the screen reader doesn't seem to see any text in the body of the site. why would that be? |
||||
|
Dont have any experience with that, but would like to help. How do you get such a screen reader? |
||||
|
There is one built into all microsoft operating systems. It's in the ease of access center. Called Screen Narrator. In a Mac it's called VoiceOver. Here is a link to what is expected. https://www.w3.org/standards/web... |
||||
|
Thinking about writing the screen readers info invisible so that only the readers see it. that way they get the info in a order that makes sense and doesn't mess with the site. |
||||
|
Unfortunately, I'm having the same problem. Did anyone find a solution? |
||||
|
To gore more into detail: I tried reading the website via NVDA and ChromeVox but none of them was able to read the text. Any text on a button and the header works fine, but any other text only works if I mouse-click on it. The containers apparently cannot get accessed by the tab-key. |
||||
|
You can tab through all clickable elements like buttons and links. Screen readers usually read what is under the cursor. Works all fine for me with rocketcake since version 6. |
||||
|
Is there a way to make the text blocks navigable by keyboard too? Usually, a blind person wouldn't really use a cursor for the screenreader. |
||||
|
Yes, for that, you can right-click the container, then select "HTML Code...", then "additional HTML attributes" and enter tabindex="0" Then you can focus these. But I don't think it's supposed to be used like that - it's more like erik said above - only use them for stuff like links, buttons and web form elements, quote from the MDN: Avoid using the tabindex attribute in conjunction with non-interactive content to make something intended to be interactive focusable by keyboard input. An example of this would be using a <div> element to describe a button, instead of the <button> element.
Interactive components authored using non-interactive elements are not listed in the accessibility tree. This prevents assistive technology from being able to navigate to and manipulate those components. The content should be semantically described using interactive elements (<a>, <button>, <details>, <input>, <select>, <textarea>, etc.) instead. These elements have built-in roles and states that communicate status to the accessibility that would otherwise have to be managed by ARIA. |
||||
|
Thanks a lot! I will consult my supervisor again but it is great that this would be possible. |
||||
|
|
){kind=link}