Question 36

Explanation

Question

Correct Answer: Keyboard navigation

Domain: Visualize and analyze the data

Solution with Ensuring Accessibility via Keyboard Inputs in Power BI

You need a built-in Power BI accessibility feature to ensure all interactive elements of a report (e.g., slicers, buttons, charts) can be reached and activated using only keyboard inputs, aiding users who rely on keyboards (e.g., screen reader users or those with motor impairments). The "Keyboard navigation" feature meets this requirement. Here’s how it works in Power BI:

• Keyboard Navigation in Action:

  • Setup: Open a Power BI report in Desktop or Service (e.g., a dashboard with a slicer for "Year," a bar chart for "Sales by Region," and a "Reset" button). No configuration is needed—keyboard navigation is built-in and active by default, per accessibility features.

  • Usage:

    • Press Tab to move focus between interactive elements—e.g., from slicer to chart to button. Focus order follows visual layout (left-to-right, top-to-bottom), per keyboard navigation docs.

    • Use Enter or Space to activate—e.g., Tab to "Year" slicer, Enter to open, arrow keys to select "2024," Enter to apply. Tab to bar chart, Enter to drill down (if enabled). Tab to "Reset" button, Space to trigger reset, per keyboard shortcuts.

  • Result: All interactive elements are accessible—e.g., a user tabs through 5 elements (slicer, 3 charts, button) and activates each (e.g., filters to $500K 2024 sales) without a mouse, per accessibility testing.

• Verification:

  • Test with a screen reader (e.g., NVDA)—e.g., Tab to slicer, NVDA announces "Year slicer, dropdown," Enter activates, arrows select "2024," confirming full keyboard control, per screen reader support.

Why This Works

• Full Keyboard Access: Ensures every interactive element—e.g., slicers (filter "2024"), charts (drill to $100K East), buttons (reset filters)—is reachable and actionable via keyboard (Tab, Enter, Space, arrows), meeting the requirement, per accessibility standards.

• Built-In: No setup needed—e.g., works out-of-the-box on a report with 10 visuals, unlike custom solutions, per default accessibility.

• User Benefit: Supports accessibility—e.g., a visually impaired user navigates and filters sales data ($500K total) without a mouse, aligning with WCAG 2.1 (e.g., Guideline 2.1 Keyboard Accessible), per WCAG compliance.

• Domain Fit: "Visualize and analyze the data" includes leveraging built-in features to make reports accessible to all users, enhancing usability.

The Microsoft accessibility guide states, “Keyboard navigation allows users to move between and interact with all report elements using only the keyboard, ensuring full accessibility.” This directly addresses the need for keyboard-only interaction in Power BI reports.

Why Not Other Options?

• Focus Mode:

  • Issue: Focus mode enlarges a single visual—e.g., click a bar chart, it fills the screen (Ctrl + Alt + Shift + F or button), per focus mode. Accessible via keyboard (Tab to visual, Enter), but only enhances one element at a time—e.g., can’t navigate between slicer and chart in focus mode, per focus limitations.

  • Why Excluded: Doesn’t ensure all elements are reachable—e.g., slicer outside focus is inaccessible, failing the "all interactive elements" requirement.

• High Contrast Mode:

  • Issue: Enhances visibility—e.g., in Windows, enable via Settings > "Ease of Access" > "High Contrast," Power BI adjusts (black background, white text), per high contrast. Keyboard works (Tab, Enter), but it’s visual enhancement, not navigation—e.g., doesn’t add keyboard reachability, per contrast purpose.

  • Why Excluded: Focuses on color contrast—e.g., $500K bar clearer—not navigation or activation, missing the core need.

• Custom Visual Formatting:

  • Issue: Allows styling visuals—e.g., "Format Visual" > set bar color to green (#00FF00), per custom formatting. No inherent keyboard navigation feature—e.g., Tab still works, but formatting doesn’t enable it, per formatting options.

  • Why Excluded: Not an accessibility feature—e.g., green bars don’t ensure keyboard access to a slicer, irrelevant to reaching/activating elements.