Bug 1501991 adds a toolbarbutton with label children: <toolbarbutton id="identity-popup-content-blocking-category-tracking-protection" onclick="ContentBlocking.showTrackersSubview()" class="identity-popup-content-blocking-category" align="center"> <image class="identity-popup-content-blocking-category-icon tracking-protection-icon"/> <label flex="1" class="identity-popup-content-blocking-category-label">&contentBlocking.trackingProtection3.label;</label> <label flex="1" id="identity-popup-content-blocking-tracking-protection-label-allowed" class="identity-popup-content-blocking-category-state-label">&contentBlocking.trackingProtection.allowed.label;</label> <label flex="1" id="identity-popup-content-blocking-tracking-protection-label-blocked" class="identity-popup-content-blocking-category-state-label">&contentBlocking.trackingProtection.blocked.label;</label> </toolbarbutton> Accessibility doesn't use these labels as the name for the button. This is because XULButtonAccessible::IsAcceptableChild doesn't allow label children, so when Accessible::XULName iterates children looking for labels, it doesn't find any. I think we should just change IsAcceptableChild to allow label children.

Toolbar buttons in XUL can now have labels inside them to provide the actual caption for the button. Adjust the accessibility module to allow label elements as acceptable children for the toolbarbutton element so the algorithm can pick up their text for the button's name.

Pushed by mzehe@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/111154a7621c Allow labels inside toolbarbuttons to participate in accessible name calculation, r=Jamie