Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow arbitrary pre-table meta information #74

Closed
matt-dray opened this issue Jul 5, 2022 · 5 comments · Fixed by #118
Closed

Allow arbitrary pre-table meta information #74

matt-dray opened this issue Jul 5, 2022 · 5 comments · Fixed by #118
Labels
accessibility Meeting the guidelines enhancement New feature or request
Milestone

Comments

@matt-dray
Copy link
Collaborator

Should users be able to provide arbitrary content above the table, i.e. via an argument(s) to new_a11ytable()?

At the moment, users of the package can only provide information about very specific things: the title, table count, warning of notes, explanation of blanks (upcoming v0.1) and data source (arguably there should be more defined possibilities, like an explanation of shorthand).

I think it's positive to be restrictive; the whole point is that we want people to adhere to the guidance and not write anything they like above each table. However, this isn't great for situations where there's a genuine user need for specific additional information.

@matt-dray matt-dray added enhancement New feature or request discuss Point for discussion accessibility Meeting the guidelines labels Jul 5, 2022
@matt-dray matt-dray added this to the v0.2.0 milestone Jul 5, 2022
@matt-dray
Copy link
Collaborator Author

Might be easier to supply arbitrary content with an approach like #65, but would still need functions to interpret the YAML and insert each item and the table correctly into each sheet.

@matt-dray
Copy link
Collaborator Author

matt-dray commented Dec 26, 2023

This could be an argument called custom in create_a11ytable(). It would be a list of character vectors; one list-element per sheet, as many vector elements as the user wants. Each custom vector-element will appear on its own row above the table. No special styling will be applied (the same as for the non-sheet-title text).

Will need to adjust the functions that count pre-table meta rows to take account of an arbitrary number of custom rows, so that tables are inserted correctly.

@matt-dray matt-dray modified the milestones: v0.3, v0.2.2 Dec 27, 2023
@matt-dray matt-dray removed the code label Dec 27, 2023
@matt-dray matt-dray changed the title Allow arbitrary pre-table meta information? Allow arbitrary pre-table meta information Dec 28, 2023
@matt-dray matt-dray removed the discuss Point for discussion label Dec 28, 2023
@matt-dray
Copy link
Collaborator Author

For backwards-compatibility—and because they're important features to have in a sheet—arguments sources and blank_cells should be retained in create_a11ytable(), even though a user could just ignore them and supply this information as custom rows.

@matt-dray
Copy link
Collaborator Author

The arbitrary rows should support hyperlinks, as per #47.

@matt-dray
Copy link
Collaborator Author

matt-dray commented Jan 7, 2024

The custom_rows argument should come after the sources argument in create_a11ytables(), maybe?

At the moment I've put custom_rows before, so that the order of the arguments and the order of the the pre-table rows in the output will match: title, number of tables (generated automatically), presence of notes (generated automatically), meaning of blank rows, custom rows, source.

But if someone has used create_a11ytables() before v0.3 then they may have provied arguments by place and their code will error if they update the package.

Most users probably have named their arguments in create_a11ytable(), though. So maybe this is a worthwhile, small breaking change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accessibility Meeting the guidelines enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant