To do list for the datatable function.

• css: integrate css from other repository. Maybe sass files would be better?
• css for cell values: using the new helper function cell_attribute, create corresponding css classes and/or evaluate the naming system for classes. This will need further discussion as to if this is appropriate for the scope of this package as conditional formatting is creates more accessibility concerns.
• fix logic for helper functions: There's likely a better way to handle the evaluating the classes and data types of cell values.
• integrate module testing: integrate the test script from the other repo
• Create wiki: create a new wiki for this package and add documentation for this function

Issue #20 of the shinyAppTutorials repository, started the development of the listbox component for shiny. This component is an alternative to select input, which is a bit hard to style using CSS. Import this component into this package.

There are few things to improve on.

• CSS Naming: standardize the classnames and align them with the package-wide system
• Scroll: when the menu is opened, the scroll state is a bit wonky. The focusing to selected item and of new items can be improved.
• Adjust height: make sure menu opens to a large enough height to avoid scroll. This would eliminate the need for extra voice commands, navigation, etc. (Consider using relative positioning rather than absolute with overflow)

The following improvements to the datatable are needed.

• Improve the naming convention of helper functions: this is probably a bit far down the list of "needs", but it is probably better to get this done early. The names of helper functions could be improved to make them more memorable. Rethink the names of the functions and come up with a naming system that could be reused in other component.s
• Add more options to control the styling of the table output: more options to control the rendering of style (i.e., css attributes) is needed for non-shiny usage. For example, disabling the rendering of classes and injecting the html dependencies altogether. This would be useful if a user needs a simple html table generator
• Improve the handling of component defaults: the current method is not ideal. Instead, the style and options arguments should passed in through .... A new argument validation function will need to be written. Consider moving the css argument into style. Move documentation for these arguments to a new section

An accordion component is useful for collapsing and expanding content. The following list provides the steps required to develop this component.

• Create helper functions: like the datatable function, create child elements using secondary functions. Create a function that builds the heading element and the collapsible section, as well as validate props (i.e., optional arguments)
• Create icons: the accordion's state is updated using a toggle (i.e., open/close button). The button is a plus icon with a filled background. Create a new functional component that will be used to render svg icons in the browser.
• Define CSS: define the default theme for the accordion. (use the travel app example as the base)
• Write Unit Tests: In a new file in tests/testthat create a series of tests that evaluate the html markup of the accordion component.
• Develop JavaScript Functions that open/close the accordion

It has been a while since I've worked on this package. Since the last updates, I have rebuilt the browsertools package and have developed the rheroicons library. These packages should be integrated into accessibleshiny in favor of lightweight icons and optimized JS code. In addition, the following changes need to be made.

• Rename the inst/assets to something more memorable and to prevent conflicts with other packages.
• Expand use_* function to allow for the following.
  • setting the document language
  • setting the document direction
  • setting the document title
  • setting open graph data Will not implement
• Update accordion component
  • replace icon with rheroicons
  • Use Shiny input bindings for toggle to handle the opening/closing of the card. The current method does not find elements that are rendered dynamically.
• Updates/Checks for Progress bar
  • Consider alternative rendering methods for progress bar. There are some instances where page rendering triggers a complete redraw of the progress bar.
  • Consult with docs regarding updating aria props
• Datatable component
  • Consider options for multiple column headers
• [ ] Integrate Parcel 2.0. (This will be ongoing as parcel2 is still in beta)
• [ ] Update dev dependencies

Generating the markup does a fairly nice job with smaller datasets. However, there are noticeable performance issues for larger datasets (i.e., > 1000 rows). The ideal use of the datatable function is to prevent production-ready, accessible datatables. It isn't really ideal for larger datasets as data tables in production apps should use smaller datasets. Regardless, the evaluation of cells and corresponding markup should be optimized. Since purrr is already a package dependency, markup generating functions should incorporate map functions.

TODO

• Reduce the number of evaluations that are performed
• Integrate better mapping functions for generating cell-level markup