Forum Discussion

umohammadumoham's avatar
umohammadumoham
Community Member
7 days ago

NVDA Keyboard Navigation Issue in Process Block (Step Progression)

I’m testing the Process block for keyboard and screen reader accessibility using NVDA and wanted to confirm expected behavior.

Initially, NVDA reads the step buttons (Step 1, Step 2, etc.) along with the left/right navigation arrows, and then proceeds to read the content of Step 1. After the Step 1 content is read, pressing Tab moves focus to the next interactive element in the following block, rather than moving to Step 2.

At the moment, the only way to reach Step 2 is by using Shift + Tab to go back to the step buttons and activating it.

Is this the expected keyboard interaction for the Process block, or should Step 2 be part of the natural tab order immediately after the Step 1 content?

accessibility

1 Reply

  • SamHill's avatar
    SamHill
    Super Hero
    1 day ago

    Hi umohammadumoham​ this is correct. This is something I have raised with Articulate in the past as I don't think the reading order is correct for the first step in the process.

    In my opinion, the reading order should be more like this:

    1. Introduction slide content
    2. Slide Controls
      1. Go to slide introduction button (current), Go to slide…etc
      2. Go to Previous slide button
      3. Go to Next slide button

    The biggest issue for me is that the current reading order puts the controls before the content of the Introduction slide. I think screen reader users could miss the content on the introduction slide, by accidently navigating to a new slide before arriving at the content of the introduction slide.

    1. Slide Controls
      1. Go to slide introduction button (current), Go to slide…etc
      2. Go to Previous slide button
      3. Go to Next slide button
    2. Introduction slide content

    The user selects Go to Next slide button (to Step 2), the order is then:

    1. Slide Controls
      1. Go to slide introduction button (current), Go to slide…etc
      2. Go to Previous slide button
      3. Go to Next slide button
    2. Step 2 slide content <- Screen reader focus is sent here. SHIFT+TAB required to find the Slide Controls.

    I find this order and navigation confusing when testing with screen reader. It doesn't feel logical to have to SHIFT+TAB to find the controls. I think my preference would be something more like this:

    1. Introduction slide content
    2. Slide Controls
      1. Go to slide introduction button (current), Go to slide…etc
      2. Go to Previous slide button
      3. Go to Next slide button

    Then for the slides after the introduction:

    1. Go to slide introduction button (current), Go to slide…etc
    2. Go to Previous slide button
    3. Step (x) slide content <- Screen reader focus is sent here. User can continue to the Next slide button after reading the content.
    4. Go to Next slide button

    For me it makes more sense that the Next slide button would occur after the slide content, and the previous button would be before the slide content, although I think the pattern used for the Introduction slide could be just carried through too:

    1. Step (x) slide content <- Screen reader focus is sent here. User can continue to the Slide controls after reading the content.
    2. Slide Controls
      1. Go to slide introduction button (current), Go to slide…etc
      2. Go to Previous slide button
      3. Go to Next slide button

    Getting rid of the need to SHIFT+TAB would be good as it doesn't feel right when your trying to read through the natural flow of content. It feels counter intuitive.