search

GSA / openacr

OpenACR is a digital native Accessibility Conformance Report (ACR). The initial development is based on Section 508 requirements. The main goal is to be able to compare the accessibility claims of digital products and services. A structured, self-validated, machine-readable documentation will provide for this.
https://gsa.github.io/openacr/
Other
83 stars 18 forks source link

Anchor links in chapter help text need to open sections in major browsers #288

Closed qjac closed 2 years ago

qjac commented 2 years ago

The links currently only work if the first section is already expanded https://gsa.github.io/openacr-editor/chapter/success_criteria_level_a#1.1.1-software-editor.

Expand the first section by default, or expand when the item is clicked. Expand on click is preferred.

Safari, Edge, Firefox tested and the anchor links do not work. Chrome works by default.

Relevant links to discussion:

dmundra commented 2 years ago

I believe that the previous code only works when you go to the the page with an anchor link in the address but not for a clicked link. So not an issue there but that code doesn't help us with the bug. FYI, we have a test for that in anchor.test.js

I am surprised that only chrome just makes it work.

Anyway I think we need something from here https://stackoverflow.com/questions/48100490/how-to-anchor-to-target-element-inside-html-details and it can target be in the component and target links in the div.

dmundra commented 2 years ago

We can do test driven development (TDD) for this!

dmundra commented 2 years ago

After looking at this together we decided it would be easier to move the text from YAML into Svelte so we can handle the links with Svelte functions. A little bit harder to maintain for content editors but it is similar to editing the Overview page and not a lot of code in the way. This should also help fix the #290.

dmundra commented 2 years ago

@qjac I rebased the branch https://github.com/GSA/openacr-editor/tree/handling-links-in-chapter-help-text with the 'disabled' changes.

qjac commented 2 years ago

Any foreseen issues with opening the first accordion on click? @dmundra

In order for us to pull out the href of the click target and use it in a querySelector, we would need to add escape characters before the '.' in the href/ids (it chokes if we just pop in the variable). To use it with getElementById we need to remove the preceding '#' from the string value. In order to open the first accordion on the page, we don't need to use or manipulate the href at all. It is a simpler implementation (which I like), but I want to make sure there isn't a downside that I'm missing that would require the more specific implementation that opens the parent accordion of that specific href destination.

dmundra commented 2 years ago

@qjac I don't think so. I would say you want to just check the 'expand all/collapse all' buttons still behave correctly which I presume they should.

qjac commented 2 years ago

@qjac I don't think so. I would say you want to just check the 'expand all/collapse all' buttons still behave correctly which I presume they should.

I haven't tested it thoroughly/methodically, but collapse all seems to stick sometimes when a detail is open. Not just the first one and it seems unrelated to this issue. On the live site in chrome and firefox if I manually expand sections, the 'collapse all' continues to have a strikethru and does not close the open drawers when pressed. I planned to make an issue about it.

dmundra commented 2 years ago

That sounds good. Thank you for testing it.