Skip to content

[BUG] dcc.Dropdown unreachable via tab key navigation #3673

Closed

Description

@m6ti

Describe your context
Please provide us your environment, so we can easily reproduce the issue.

  • replace the result of pip list | grep dash below
dash                       4.0.0
dash-bootstrap-components  2.0.4
  • if frontend related, tell us your Browser, Version and OS

    • OS: [e.g. iOS] MacOS
    • Browser [e.g. chrome, safari] Safari
    • Version [e.g. 22] Version 26.3 (20623.2.7.18.1)

Describe the bug

dcc.Dropdown components are not reachable via tab key navigation in Dash 4.0.0. In Dash 3.4.0, dropdowns were naturally part of the tab order and could be focused, opened, and navigated entirely via keyboard. In Dash 4.0.0, pressing the tab key skips over all dcc.Dropdown components, making them inaccessible.

Expected behavior

dcc.Dropdown should be focusable via the tab key, matching the keyboard accessibility behavior of Dash 3.x. Users should be able to tab through a form containing dcc.Input and dcc.Dropdown components sequentially, and once focused, interact with the dropdown via keyboard (type to search, arrow keys to navigate options, Enter to select).

Screenshots

If applicable, add screenshots or screen recording to help explain your problem.

Activity

  1. AnnMarieW commented on Mar 19, 2026

    @AnnMarieW
    Collaborator

    Hi @m6ti

    I can't duplicate the issue - can you please elaborate? When I run the sample app below, I can focus on inputs and the dropdowns using the tab key and it does not skip over the dropdown components.

    Note that in the next release, there is a fix to make it possible to search without opening the dropdown first. Is that what you are referring to? #3627

    from dash import Dash, dcc, html, Input, Output,callback
    
    app = Dash()
    app.layout = html.Div([
        dcc.Input(id='demo-input1', type='text'),
        dcc.Dropdown(['NYC', 'MTL', 'SF'], 'NYC', id='demo-dropdown'),
        html.Div(id='dd-output-container'),
        dcc.Input(id='demo-input2', type='number'),
        dcc.Dropdown(['NYC', 'MTL', 'SF'], 'NYC', id='demo-dropdown2'),
    ])
    
    
    @callback(
        Output('dd-output-container', 'children'),
        Input('demo-dropdown', 'value')
    )
    def update_output(value):
        return f'You have selected {value}'
    
    
    if __name__ == '__main__':
        app.run(debug=True)

    `

  2. m6ti commented on Mar 20, 2026

    @m6ti
    Author

    I've ran that exact code and for me on version 4.0.0 pressing tab skips the dropdowns entirely. 3.4.0 doesn't skip the dropdowns.
    https://github.com/user-attachments/assets/721b2e87-a461-4825-8c29-8b2b0ce5b35d

  3. T4rk1n commented on Mar 20, 2026

    @T4rk1n
    Contributor

    Browser [e.g. chrome, safari] Safari

    Tried on Firefox/Linux and the tab key navigate thru all the element correctly, might be different on Safari which has an accessibility setting to enable for the that feature.

  4. m6ti commented on Mar 23, 2026

    @m6ti
    Author

    Checking the 'Accessibility: Press Tab to highlight each item on a web page' in Safari's 'Advanced' settings seems to produce similar tab behaviour that Dash 3.4.0 had in my larger Dash app.
    However on the minimal example above, it takes 5 Tab presses after page load to get to the first Input, then a single press to get to the first Dropdown, a single press to get to the number input, and 3 tab presses to get to the final Dropdown.

    Option + Tab results in the same navigation of elements, without the Accessibility setting checked.

  5. AnnMarieW commented on Mar 23, 2026

    @AnnMarieW
    Collaborator

    Hi @m6ti

    It looks like the Accessibility setting fixed the issue.

    The multiple tab presses after page load are caused by other focusable elements such as Dash DevTools. Setting debug=False should fix that.

    Getting to the last Dropdown requires 3 tab presses because the number input in dash 4 includes separate - and + buttons, which are individually focusable.

  6. pinned this issue on Mar 24, 2026
  7. camdecoster commented on Mar 25, 2026

    @camdecoster
    Contributor

    I'm going to ask our principal DCC developer to take a look at this issue, but we might end up closing the issue since it doesn't seem to be a widespread problem. Thank your for bringing it to our attention.

  8. KoolADE85 commented on Apr 7, 2026

    @KoolADE85
    Contributor

    FYI, I will be picking up this issue - I have reproduced it reliably on Safari as well.

  9. camdecoster commented on May 6, 2026

    @camdecoster
    Contributor

    Closed by #3740.

  10. unpinned this issue on Jun 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions