Is there intent to upstream features?

[seanpdoyle]

I've found a lot of value in this Gem's collection of features. Does the team have any intentions of upstreaming any features to teamcapybara/capybara or rails/rails?

There are some similarities and overlapping features. For example:

• teamcapybara/capybara declares a validation_message filter to make assertions about HTMLObjectElement.validationMessage, whereas capybara_accessible_selectors declares validation_error, which asserts about aria-invalid, HTMLObjectElement.willValidate, and in-HTML messages
• rails/rails declares a <trix-editor>-specific rich_text_area selector, whereas capybara_accessible_selectors declares rich_text. There is an opportunity here to merge the selectors to filter on the presence of role="textbox" and contenteditable
• teamcapybara/capybara declares partial support for <details>/<summary> element pairings, and capybara_accessible_selectors declares disclosure and disclosure_button selectors

Outside of those overlapping features, focused: and fieldset: feel valuable outside the context of being "accessible selectors", and could be welcomed additions upstream.

[luke-hill]

Probably one for @mrdaniellewis I'd say?

[seanpdoyle]

@luke-hill @mrdaniellewis have either of you had an opportunity to consider these questions?

Since the project is not listed on RubyGems, it can only be consumed as a dependency through a Gemfile declaration with github: "citizensadvice/capybara_accessible_selectors", tag: "...".

Are there plans for the project's future as a published RubyGem? Do you intend for other projects to utilize it? Do you have an interest in accepting contributions from the community? Would you teams be better suited to fork the project than to depend on it directly?

[luke-hill]

I'm no longer working for CA @seanpdoyle .

I had this question for another sub-gem I developed here - ca_testing. However after leaving I spoke to the only other contributor and I then open-sourced it under the site_prism banner as automation_helpers

One of the big(ger), issues was that we never had any policies or protocols, so we didn't really know who to speak to or what the rules were (In terms of pushing it up). I think @pedanticgit might be able to advise here better than I can or failing that Dan again.

[mrdaniellewis]

Hi

I wasn't planning on upstreaming anything. Although I do think you are right there some candidates in here that could be useful in core Capybara.

Looks like they did add a focused filter last year. They also have made some tentative steps in supporting aria roles, although only on buttons.

Some of the selectors in this library are based on aria practices. This is useful standard to work to, but it can be a bit fluid, and therefore probably not a good candidate for upstreaming. For example the disclosure, modal, tab and combo-box selectors and actions.

Some of the selectors are also a bit idiosyncratic, such as the validation ones, as there is more than one right way to do this, so again are probably not good candidates.

I think the fieldset and described by ones could be candidates to include in Capybara.

I'd agree the Rails selector for trix should be more generic. Although that probably isn't their goal with that selector. And unless I'm missing something, the trix editor isn't particularly accessible.

I'm open to putting this on RubyGems. I'll need to sort out some admin issues before I can do that, though.

Also my notification settings were broken so I wasn't getting notified about PRs. I will look at all of them.

[seanpdoyle]

Thank you for the response, @mrdaniellewis.

Looks like they did add a focused filter last year.

I'm happy to admit that I'm responsible for upstreaming the focused: filter (https://github.com/teamcapybara/capybara/pull/2490).

They also have made some tentative steps in supporting aria roles, although only on buttons. ... I think the fieldset and described by ones could be candidates to include in Capybara.

I tried to upstream the described_by: filter (https://github.com/teamcapybara/capybara/pull/2491), but it was ultimately rejected. With that being said, upstreaming the fieldset: filter might still be worthwhile.

I'm open to putting this on RubyGems. I'll need to sort out some admin issues before I can do that, though.

From a technical perspective, I'm perfectly content depending on the gem through GitHub. My question is more rooted in uncertainty around the goals of the project. Publishing it through RubyGems might help legitimize it as a viable dependency to skeptical teams.

Also my notification settings were broken so I wasn't getting notified about PRs. I will look at all of them.

Thank you for your time! There are still a handful of ad-hoc selectors created for projects that feel appropriate to contribute. If you're interested in accepting contributions from the community, I'm happy to continue to open pull requests. If you're open to it, I'd also be happy to help maintain the project.

With that being said, if you aren't interested in accepting contributions, that's reasonable too! I'm just as happy to create a fork, but I wanted to clarify your team's intentions about maintenance and the project's future before doing so.

[mrdaniellewis]

Thanks for your contributions.

I'm on holiday for a couple of weeks so won't be able to progress adding it to RubyGems until after that.

I should be able to at least cut a new version Monday, though.

There are a few odds and ends I intend to add in the future such as something to handle aria-live areas, and a general accessible_name node filter which would would be a more spec compliant version of the existing aria-labelledby filter.

[seanpdoyle]

a general accessible_name node filter which would would be a more spec compliant version of the existing aria-labelledby filter.

I have always wanted this, but always got discouraged when I started to work my way through the specification's algorithm. I'd love to see that kind of support added!