> On Oct 22, 2017, at 3:35 AM, smaug <sm...@welho.com> wrote: > > On 10/21/2017 11:45 PM, Yura Zenevich wrote: >> I would also like to bring to the team's attention another force worth >> being on the radar (in terms of "forces on the system") - accessibility. >> One theme that seems to consistently happen with re-writes such as the ones >> from xul to React is regressions in terms of accessibility of newly >> re-written components. >
Thanks, I’ve submitted a PR to the plan to add this point. > Yeah, this is important. I would imagine custom elements in XUL (which might > then internally use shadow DOM too) would implement the same > a11y interfaces what XBL implements now. I agree - if we migrate the logic inside of bindings (i.e. formatAccessKey on <label>) and continue to use XUL Elements this should limit the risk of regressions. Two places we should take a closer look at: 1) Ensure that anonymous XBL content is not somehow handled differently from an accessibility standpoint compared to normal DOM children in a Custom Element (or content inside Shadow DOM) 2) We may need to emulate the [role] attribute on a binding definition, which does map to some accessibility code. Do we need to change the way we create the appropriate Accessible class for Custom Elements? It does look at XBLBindingRole as a way to choose which role to assign (i.e. role=”xul:toolbar” on the binding definition). For Custom Elements, it may be easier to use tag names to determine the role, or somehow store it in the custom element registry to avoid setting a ‘role’ attribute on each node during the connectedCallback. ** https://dxr.mozilla.org/mozilla-central/rev/69e24c678a28dc46a4c1bda3ff04b2f6106ff71a/toolkit/content/widgets/button.xml#12 ** https://dxr.mozilla.org/mozilla-central/rev/69e24c678a28dc46a4c1bda3ff04b2f6106ff71a/accessible/base/nsAccessibilityService.cpp#1380 >> >> thanks, >> yura >> >> On Sat, Oct 21, 2017 at 6:14 AM, Philipp Kewisch <mozi...@kewis.ch> wrote: >> >>> On 10/20/17 7:47 PM, Dave Townsend wrote: >>>> For some time now we've been talking about moving away from XUL and XBL. >>>> The browser architecture team has been hard at work figuring out how to >>> go >>>> about doing that and we're ready to share the first of our proposals more >>>> widely. We have developed a plan to remove XBL from Firefox. It's been >>>> through a successful design review with some of the key engineers and now >>>> is the time for more comments if you have them. We're planning to start >>> some >>>> of the work this quarter with it really ramping up next quarter. >>>> >>>> Take a look at the plan >>>> <https://mozilla.github.io/firefox-browser-architecture/ >>> text/0007-xbl-design-review-packet.html> >>>> and let us know what you think. There are a couple of areas where we are >>>> still investigating concerns: >>> >>> I very much welcome this plan, especially the fact that Web Components >>> is part of the replacement. Last time I asked, it sounded like Web >>> Components was still on the way of being reimplemented and pending some >>> spec work. In following the webcomponents bug I see there has been >>> constant progress. >>> >>> Nevertheless, I'd appreciate if someone could comment on how far along >>> the Web Components implementation is. Is it now following the agreed >>> upon version of the spec (I suspect yes), and is the implementation >>> stable enough that you would consider it ready to ship? What is the next >>> big milestone for Web Components? >>> >>> Thunderbird/Lightning uses a lot of XBL components as well that I would >>> love to get rid of, I am looking forward to making things more >>> compatible with the future. >>> >>> Thanks, >>> Philipp >>> >>> >>> >>> _______________________________________________ >>> dev-platform mailing list >>> dev-platform@lists.mozilla.org >>> https://lists.mozilla.org/listinfo/dev-platform >>> > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
