Firebug Accessibility Roadmap

From CodeTalks

(Redirected from Firebug Roadmap)

Image:Example.jpgThis is a planning document only. At the moment it's basically a wish list for future Firebug development so that it supports WAI-ARIA testing and web accessibility testing in general.

Contents

Integrate with mainstream developer tools

  • Firebug integration
    • As much as possible, integrate into other features
    • Some special a11y features may be added to accessibility tab, perhaps at first in a separate Firebug extension
    • Make Firebug itself accessible (some panes are HTML, so actually need WAI-ARIA to do it)
  • Web developer toolbar integration

Support standards

  • Priority 1
    • HTML 4.01
    • HTML + WAI-ARIA + tabindex changes
    • WCAG 2.0 validation
    • Allow support for non-standard attributes such as dojoType
  • Priority 2
    • SVG + WAI-ARIA
  • Priority 3
    • HTML 5

Test correctness -- instantaneous checks (validation plus some)

  • Modify Firebug Inspect Utility to assist with accessibility checking
    • Add option to active accessibility test features
    • All accessibility test facilities must be accessible
    • Ensure all test features work on dynamic content changes as well as page load
    • Perform HTML View enhancements with accessibility test features are enabled
      • Highight elements with role values that are missing or have invalid tabindex values
      • Highlight incorrectly spelled roles such as through a squiggly line under misspellings
      • Visually flag incorrect markup combinations of roles and states on an element. - Aaron get with John Resig to see if unit test framework will address.
      • Incorrect markup combinations (such as aria-checked on role="grid") - Aaron get with john resig to see if unit test framework will address.
      • Allow the author to manipulate key accessibility states and properties to ensure triggering of script/CSS to trigger UI changes. This is to ensure the UI can respond to changes by assistive technologies
    • Create new accessibility test Panel for WAI-ARIA for element level testing
      • Indicate incorrect structure in ARIA container widgets. Need a way to specify design pattern matching for firebug. This needs to be extensible and well documented.
      • Flag missing keyboard handlers
      • Indicate to author improper style guide implementations
      • Flag WCAG 2 failures at the element level
      • Flag absence of focus and blur event handlers on focus able items for styling
  • Error determination should be based on an extensible validation criteria for consultants
    • Work with Henri Sivonen (Validator.nu) and W3C PFWG to define good rules

Test usability -- dynamic tests

  • Focus tracker to view ARIA properties and states of the element that has focus
  • Warn on possible missing semantics
    • Content that changes or becomes visible should be in live region (aria-live) or use role that describes type of change (timer/log/status/alert/progressmeter)
    • Content that shows a background color change on focus or mouseover and has no semantics
    • Heuristic that can determine if something is document vs. dialog/application
    • Look for landmarks (main/navigation etc.)
  • Dyamnic Rules based testing facility - Tentative: Mike Squillace lead with community participants
    • Check tabindex values to make sure they are updated properly for multi-role widgets
    • Investigate John Resig's Fireunit test framework and how ACTF rules processing capability could be duplicated in browser extension
    • Validate against keyboard style guide
    • Validate against ARIA Best Practices Guide design patterns for widgets
    • Element focusability based on role
    • Keyboard shortcuts
    • Based on clicks or key presses ensure correct state changes
  • Types of dynamic tests
    • Automatic, click and press keys to interact with the page for the author
    • Run through a prerecorded (tester-defined) script tailored for the page, to check for new regressions
    • Simply log errors as user manually works with the page

Report errors and warnings

  • Mike Squillace to investigate reporting formats, and how a firefox extension could support a reporting tool
  • Reporting Tools
  • Highlight errors
  • Ability to set a breakpoint based on specific test failures
  • Provide log view with links to more info about the relevant a11y topic (both a11y guidelines like 508/WCAG and technical docs)
  • Export errors in EARL format
  • Show dynamic changes to the dom as they occur
  • When possible tie back to WCAG/508 etc. Also, be able to create report sorted by checkpoint

Features by ARIA topic (TBD)

  • Landmarks
  • Widgets
  • Live regions
  • Drag and drop

Potential Firebug ARIA Extension Features

  • Additions to HTML Tab
    • Show HTML for the element with current keyboard focus in web page
      • Currently firebug ("Inspect Element" feature, control+shift+C) supports inspection of elements based on mouse position, but not keyboard focus
      • Should work exactly the same for keyboard focus changes as it does for mouse pointer changes
    • Update DOM View in right hand panel to show the element that has focus in the HTML panel. Additional features include:
      • Calculated accessible name
      • Calculated description
      • Role information
      • Tabindex value
      • Current values of ARIA properties and states
      • Change ARIA property and state values to test if author's scripting responds to assistive technologies updating ARIA values
      • Invalid or errors in usage of aria properties and states
      • Invalid values for aria properties and states
      • Accessible tree view (important when owns property is used)
  • A11y Panel
    • Tree view of ARIA widgets, regions and landmarks
      • Expanding the tree would show encapsulated widgets
      • Render design pattern structural errors and suggest fixes
        • Structural (Encapsulation of sub roles or use of owns property)
        • Keyboard (Information of which keyboard event handler(s) would process events on the element being inspected)
        • Structural vs. setsize/Posinset alternatives
        • Structural vs. owns representation of structure (suggest solutions)
      • Special node to view properties and states
      • Indication of errors
  • Updated Scritping Panel
    • A11y Filer Option: Add a feature view watched and break points associated with ARIA markup
    • Errors feedback panel
    • A11y panel from the HTML Tab
    • Initial tree view based on location of focus in the web page
    • Update tree view based on changes in focus on web page
    • Update page focus based on tree item selected
    • Link/Button to go to HTML Tab of the currently selected widget
  • New Live Region Tab
    • List of live regions (left panel)
    • Live region properties (right panel)
      • Role (if any)
      • Current value of atomic
      • Current value of busy
      • live
      • relevant
      • Subtree DOM information
    • Link/Button to go to HTML Tab of the currently selected widget
    • Indication of node that are changing that currently do not have a live region role
  • Drag and Drop Tab
    • Left hand panel would list items that are grabable
    • Right hand panel would list the items that have aria-dropeffect defined and the value of drop-effect.


  • Error Reporting in DOM panel
    • Error feedback should indicate author actions
      • Section 508 and WCAG 2.0 problems based on iCITA HTML Best Practices rules
      • Invalid ARIA roles, suggest from context
      • Invalid ARIA attributes, for the role (including attributes that are not defined in spec)
      • Invalid ARIA attribute values, list valid values
        • Example: aria-checked="yes" would be marked as an error and the proper usage aria-checked="true | false" would be provided
      • Missing ARIA best practices
        • Example: aria-labelledby or aria-label on a role="application" or role="document"
      • Missing roles suggestion from context of widget
      • Missing keyboard event handlers
      • Missing tabindex values
    • Printable view of errors
    • EARL formatted export of errors
  • Section 508 and WCAG 2.0 Compliance Reports
    • Provide a reporting system for people to get a Section 508 or WCAG 2.0 compliance report on the current page in the DOM, similar to current VPATs
    • An initial set of compliance rules could be based on iCITA HTML Best Practices and new ARIA rules
    • Make reports available in an XML format for collection by an external application (see next section)
  • Remote Configuration and Reporting Facility
    • Allow the user to specify a host system to send and track compliance
    • Allow the host system to configure the Rules engine for tracking
    • Allow the user to begin logging session with an identified task
    • Report problems back to host system for tracking

Current Firebug Features

  • "Inspect Element" feature supports mouse pointing to elements, but does not support inspecting the element with keyboard focus (unless you point to it with the mouse of course)
  • DOM inspection of aria attributes and values
  • View HTML with ARIA attributes and values
  • Updated ARIA values

Ideas

  • Provide a view of the accessible object tree and events (based on current platform?) -- (Aaron: I suggest this should not be needed once we get past the bleeding edge stage of ARIA, it will only serve to confuse authors. In any case, there are other a11y tools for that)
    • Rich Comment: should this not be the job of accprobe or an equivalent?
    • Aaron Comment: if we want this can be done via Firefox's scriptable accessibility interfaces (nsIAccessible/nsIAccessibleTable/nsIAccessibleText/etc.). This is what Firefox's DOM Inspector does. It lets you see a11y info right next to the object in the DOM. You can also have it highlight all the nodes that have accessible objects associated with them. It's somewhat reinventing the wheel, but for something like accessible name, I suspect that people may want to see exactly what the browser has decided that is.
  • Focus inspection tool that provides information about the the current role. There is an intial implementation is available in the Beta version of the Firefox Accessibility Extension from the University of Illinois.
  • Use Fire Vox for simulation

Work items

  • Figure out separation of what goes into actual Firebug extension and what should go into a separate extension to the extension
  • Determine what rules engine to use
  • Determine what we need from each of the existing plug-ins. ... Too many
  • Talk with major accessibility test tool providers to see how we can support them as well

Links to Firebug Resources

Retrieved from "http://wiki.codetalks.org/wiki/index.php/Firebug_Accessibility_Roadmap"