Does Mac VoiceOver limit its functionality on Chrome / Firefox?

The answer is more likely to be the opposite of how you phrased the question.

Does Mac VoiceOver limit its functionality on Chrome / Firefox?

Generally, no. Web developers often assume the screen reader is the problem, but it's often the web browser's implementation that is lacking. When HTML and ARIA semantics are conveyed as expected with one browser, but not with another browser, using the same operating system and screen reader, this usually points to a difference in the browser's implementation.

Screen readers don't read web pages directly. Instead screen readers (and other assistive tech) communicate with web browsers (and other native applications) via an accessibility API provided by the operating system. The screen reader can only report what it has been told by the web browser. Web browsers need to pass the accessibility metadata to the operating system, which in turn is available to the screen reader. Firefox in particular is does not work well with the macOS accessibility APIs.

WCAG uses the term "accessibility supported" to describe this. Basically, these ducks must all be in a row:

• The web page developer uses HTML and ARIA correctly. Note that ARIA has a content model; some roles/properties are expected to be used in combination with other properties and children's roles.
• The web browser implements HTML and ARIA semantics correctly, and exposes this to accessiblity APIs on the host operating system, with correct mappings.
• The accessiblity APIs provided by the host operating system must also model the same information.
• The assistive technology (screen readers, etc.) uses this to inform the user what's on screen, and pass their interactions back along the reverse route. Screen readers have varied design philosophies on how best to present this: they provide user preferences to control things like verbosity and punctuation; and tools for inspecting document structure or listing links.

That said, some screen readers like JAWS can hook directly into the browser process, because historically that was the best way to do things, before the accessibity APIs were developed. I've heard that some assistive tech may engage custom behaviours as workarounds for browser bugs, but I can't provide a citation for a good example. Looking to the future, the proper way is the use of OS-level accessibility APIs, which OS vendors may enforce at some point. Screen readers do have user-script capabilities, and some vendors distribute scripts (hacks) to enhance particular websites.

Further information:

• Accessibility APIs: A Key To Web Accessibility is a good introduction to the topic.
• WhatSock's Accessibility Tree Training Guide goes into more depth.
• PowerMapper have published extensive Screen reader reliability information. Detailed test results compare many combinations of browser, OS, and screen reader.
• Browser dev tools now provide a way to inspect the accessibility tree (Firefox, Chrome). This shows what a browser is sending to the OS-level accessibility API.
• To inspect the accessibility information as it passes through the OS-level accessibility APIs, you can use aViewer (Windows), or the XCode Accessiblity Inspector (macOS).
• The expected behaviour for mapping web content to OS-level accessibility APIs is described in various W3C documents: Core Accessibility API Mappings, HTML Accessibility API Mappings, SVG Accessibility API Mappings, Accessible Name and Description Computation. Browser vendors are expected to implement these.
• The bug trackers for various screen reader software often provide insight on whether a particular quirk arises from the browser or screen reader.