Forum Discussion

sonl's avatar
sonl
Community Member
5 days ago

Custom Blocks Accessibility/Screen Reader testing

Hi all, I’m having an issue with Tab-based keyboard navigation not working, and I’m looking for a fix or workaround for accessibility/screen reader testing.

I have custom blocks throughout, but when I tab through them, it goes straight to the next interactive button, like the Continue button divider.

What’s odd is that later in the lesson, tabbing does detect a paragraph field within the custom block.

My current block setup is Canvas > Shape > Text and Icon Image. I tried adjusting the focus order, but that didn’t help.

To reproduce it: add a introduction template custom block, then create a blank canvas > add a shape > add a text box inside the shape then add a Continue divider, and open preview mode. When tabbing, it will detect the Introduction heading, then skips the custom block and goes directly to the continue button.

I found a similar thread that matches my situation: https://community.articulate.com/discussions/discuss/custom-blocks-accessibility/1238624


Hope to hear from you all soon :)

accessibility
advice
Articulate 360
e-learning development
instructional design
rise 360

3 Replies

  • marvie_ctr's avatar
    marvie_ctr
    Staff
    21 hours ago

    Hi Sonl!

    Tabbing is intended to move focus between interactive elements. If your custom block contains only headings, paragraph, images or shape, these are static content and are not expected to receive keyboard focus.

    When using a screen reader, non-interactive content is typically accessed through the browse or reading mode. Depending on what screen reader you are using, you’d typically use the up/down arrow keys to move through the content instead of tabbing. For example, using NVDA with Firefox, you can use up/down keys to navigate through the content, while VoiceOver with Safari, you use CTR + OPT + Left/Right arrows.

    That said, you mentioned that a paragraph in your Custom Block is receiving keyboard focus. I suspect this may be because the paragraph is scrollable, so the scroll is receiving the keyboard focus. It may be subtle, but you can verify this by editing the paragraph in the custom block, expanding the text container to comfortably fit the text, and try again.

    I'd be happy to take a closer look too, to be certain, if you can share a link to sample.


    Cheers!
    Marvie

     

    • sonl's avatar
      sonl
      Community Member
      11 hours ago

      Hi marvie_ctr​ !

      It all makes sense now, in this case you are correct - The interactive elements in the text field was scrollable hence why I was able to tab towards it.

      In saying this - is there any possible workaround or is this simply just a limitation as of present?

      Kind Regards,

      • marvie_ctr's avatar
        marvie_ctr
        Staff
        2 hours ago

        Hey sonl​ !

        Glad to hear that was it! This is actually intentional for fixed-layout. The scroll mechanism is in place to ensure that text remains visible and accessible even if it becomes larger than the available space. For example, if you change to a font that takes up slightly more space than the original, or for when the content is translated and the text becomes longer. I'll check that the fixed-layout template where you encountered this is adjusted. 

        The better solution is start authoring in responsive layout, and using the responsive templates, to avoid the text scrolling altogether 😀. 

        Cheers!
        Marvie