wiki:WebKitAccessibilityPerformance

WebKit Accessibility Performance

by Nan Wang

  • Problems
    • “Busy” text in this state entire web page is unresponsive
    • Heavy JS with VoiceOver, can increase CPU utilization (near 100%)
    • VoiceOver indicator can have a wrong indicator, may indicate wrong activation point (no click event)
  • WebKit Accessibility Overview
    • Accessibility Flow
    • VoiceOver example on iOS
      • User gasps on the screen at (x, y)
      • VoiceOver hit-tests on the web page
      • WebCore creates AX tree
      • VoiceOver visits the AX node
      • VoiceOver announces the element
    • Why an AX tree?
      • Imagine a web form, several form elements
      • From AX API, less info, less nodes
    • Build Accessibility Tree
      • DOM Tree & Style Sheets > Render Tree > Layout > Accessibility Tree
    • Accessibility in WebCore
      • Lives in WebProcess
  • Current Challenges
    • Accessibility Tree Generation
      • constant accessibility tree validation
      • Possible re-layout
      • Slow performance
    • Many IPC calls
      • Accessibility frame retrieval
        • Sometimes retrieves coordinates for frames over and over
    • Sandboxes Web Process
      • Limitations for the system Accessibility API
      • Assistive tech are accessing the web process
      • Other browsers have different approaches
  • Solutions
    • Unblock the Main Thread
      • Reduce DOM interaction
        • Average attribute fetching time is 0.05 ms
        • On macOS constantly fetching, could be huge impact on main thread blocking
        • 10x speedup with caching
      • Define Tree Generation Timing
        • Reduce accessibility tree validations
          • 2000 updateBackingStore() calls when a user taps on an element on iOS
          • 0.02ms avg
          • 0.2 ms when a re-layout is triggered
      • Reduce IPC Calls
        • 0.2 ms when retrieving a frame on an iPhone 8 Plus
        • 20x speedup with frame caching
    • Conclusion: Cache!
      • Need to be careful to keep physical footprint low
    • Static Accessibility Trees
      • Store Accessibility Information in some sort of data structure
      • class AccessibilityStaticObject proposal
      • A lot of possible attributes
        • 50 ARIA attributes
        • 90 Attributes exposed on iOS (including ARIA)
        • More on macOS
      • Storing all values could be wasteful
      • Store a Compact Data Structure
      • About 20 attributes for each major data type
        • Use HashMap?
      • Accessibility Tree Generation
        • Class to wrap a one-time snapshot of the accessibility tree up front
        • class AccessibilityStaticObject
      • Incremental Tree Updates
        • Class to represent an atomic change to an AccessibilityTree
        • class AccessibilityTreeUpdate
        • Used to apply to snapshot tree
        • Individual actions (operation=[Add|Remove])
        • oldNode=<id>
        • newNode=<id>
      • Bounding Boxes
        • Accessibility bounding boxes are normally screen coordinates
      • Hit-Testing
        • Hit-testing onto the AccessibilityStaticObject instead of the RenderObject
        • Depth-first traversal of the tree in reverse pre-order to find the element
    • Future Work
      • Parameterized attributes
        • E.g. text bounding box
        • May require blocking main thread to query DOM tree
        • Should cache enough data
        • Maybe split text into inline text boxes
        • A sequence of same style characters within the same line
        • Store relative frame of each character
      • Pass a serialized tree to UI Process
        • Pro: break the limitations for system Accessibility APIs
        • Con: Security concerns
  • Implement Static Accessibility Trees
    • Off main thread computation
    • Separate AX tree generation
    • Reduce IPC calls by caching frames
Last modified 3 years ago Last modified on Oct 12, 2018 3:37:47 PM