Architectural Blueprint for the Bibliographic Citation Desk and Research Packet Builder

Full report

On this page

The integration of a robust bibliographic management utility within a secure, browser-based archival workstation necessitates a sophisticated synthesis of historical desktop interface paradigms and modern client-side processing capabilities. This analysis defines the architecture for the Citation Desk, an isolated, browser-local subsystem engineered for the Al.Qaeda.net Archival Reconstruction. Operating within a server-rendered PHP/HTML and vanilla browser technology baseline, the application establishes a strict ontological boundary between the immutable canonical source artifacts housed in the archive and the mutable, user-controlled research assembly maintained in the local workspace. This environment empowers researchers to seamlessly capture metadata, associate personal annotations, preserve research trails, and generate structured output formats—ranging from formal Chicago Manual of Style bibliographies to comprehensive textual research packets—without ever transmitting personal research data back to the host server. The reliance on vanilla web technologies ensures that all collection building, citation deduplication, format transformation, and export generation occur exclusively via local execution. The resulting application behaves not as a modern cloud service, but as a sovereign desktop application reminiscent of legacy reference managers, optimized for deep, private archival engagement.

Historical Benchmarking and Design Language

To maintain continuity with the application's nostalgic, recovered desktop workstation aesthetic, the Citation Desk must consciously eschew modern, whitespace-heavy web design in favor of classic, information-dense graphical user interface (GUI) conventions. Evaluating historical and contemporary bibliographic software provides the foundation for this design language.

Legacy Reference Managers: ProCite and Papyrus

Historical Windows-era software established interaction paradigms that remain highly effective for dense data management. ProCite, notably version 5.0, utilized a "workform" concept to handle diverse media types1. Rather than presenting a unified, generic form for every entry, ProCite dynamically altered its input fields based on the selected document type (e.g., manuscript, legal document, journal article), ensuring that researchers were prompted only for relevant metadata1. Papyrus (versions 7 and 8\) introduced an integrated "notecard" architecture2. It allowed users to attach an unlimited number of searchable notecards to each bibliographic reference, providing room for up to 8,000 characters of comments or quotations per card2. This relational model between the formal citation and the qualitative evidence forms the conceptual basis for linking quotes and annotations within the proposed workstation.

Contemporary Bibliographic Engines: Zotero, EndNote, and JabRef

Modern counterparts demonstrate the evolution of metadata processing and deduplication. Zotero utilizes a two-tier duplicate detection algorithm, initially checking for exact matches on title, DOI, or ISBN, and subsequently falling back to a looser check involving publication years within one year of each other and at least one shared author4. EndNote provides deep customization for archival materials, utilizing specific reference types that accommodate fields such as Collection Title, Box, and Folder6. JabRef, tailored for LaTeX workflows, relies heavily on BibTeX and emphasizes deterministic citation key generation, often utilizing an AuthorYear algorithmic format to ensure collision-free references8.

Browser Bookmark Export Traditions

The export traditions of early web browsers offer a structural precedent for generating hierarchical, locally readable files. The Netscape Bookmark File Format, which became a standard export paradigm, relied on simple HTML definition lists (\<DL\>, \<DT\>, \<DD\>) to maintain folder structures and annotations alongside hyperlinks. This methodology informs the application's approach to exporting "Reading Lists" and plain-text packets, ensuring that hierarchical groupings established in the Citation Desk are preserved in a highly portable, universally readable syntax.

Archival Provenance and the Metadata Field Matrix

A critical challenge in generating accurate citations from a digital archive is translating raw archival metadata into standard bibliographic schemas without fabricating missing information. The archive contains canonical source artifacts, which must be accurately described according to archival standards like Describing Archives: A Content Standard (DACS)11. DACS emphasizes that archival description is output-neutral and privileges intellectual content in context, functioning equally well across all material types13. Historically, library systems utilized the Metadata Object Description Schema (MODS), an XML-based standard developed by the Library of Congress to bridge the complexity of MARC 21 and the simplicity of Dublin Core14. While MODS excels in institutional repositories, client-side browser engines require a lighter, JSON-native format. Therefore, archival metadata must be mapped into the Citation Style Language (CSL) JSON format17, which serves as the underlying data structure for the local processing engine.

The Metadata Field Matrix

The mapping of canonical archival metadata into CSL JSON variables, and subsequently into output formats like RIS and BibTeX, requires precise alignment to ensure that specialized archival locations (such as boxes and folders) are not lost during transformation.

Safeguards Against Fabricated Metadata

Bibliographic software historically struggles with incomplete metadata. Systems must not automatically populate empty fields with assumptions (e.g., guessing a publication year based on an accession date). The workstation enforces a strict "Truth in Provenance" rule: if a field is absent in the canonical archive, it remains explicitly null in the CSL JSON object. To satisfy the requirement that users can edit citation displays without altering underlying provenance, the architecture implements a dual-layer data model. The base Archival Object is immutable and cryptographic, representing the server's canonical truth. When added to the Citation Desk, a Derived Citation Object is instantiated in the user's local IndexedDB. If a researcher manually alters an author name to satisfy a specific formatting quirk, the UI displays the modified field with a distinct visual indicator—such as a classic dotted underline or colored text—and provides a context-menu option to "Revert to Archival Original." This mechanism ensures personal work remains highly customizable while structurally distinguishable from archival authority.

Interface Architecture and Window Layout

The visual requirement mandates that the Citation Desk feels like a native application adjacent to the Archive Explorer, Clipboard Viewer, and Research Workspace. The workspace utilizes a classic three-pane desktop layout, heavily reliant on standard operating system control metaphors simulated via CSS.

The Split-Pane Application Layout

1. The Data Grid (Top Pane): A tabular list view displaying the current citation basket. Columns include Author, Title, Year, Source Class, and Date Added. This grid supports classic column-header sorting, enabling researchers to group items alphabetically or chronologically by clicking the headers. Drag-to-resize column boundaries provide precise layout control.

2. The Property Inspector (Bottom-Left Pane): When a citation is selected in the Data Grid, this pane displays the editable metadata fields. Following the ProCite "workform" convention1, the visible fields dynamically adapt based on the selected document type. A manuscript will expose archive\_location and call-number, while a generic web page will emphasize URL and accessed dates.

3. The Context Viewer (Bottom-Right Pane): Drawing inspiration from Papyrus's linked notecards2, this pane aggregates all qualitative data associated with the selected citation. It displays user annotations, captured quotations, and the surrounding text context extracted from the archival source, maintaining a continuous link between the formal metadata and the raw evidence.

Menu Bars and Toolbar Integration

The interface incorporates a classic semantic menu bar positioned at the top of the application window. The menu structure includes File (Import, Export, Print Preview), Edit (Undo, Redo, Copy Citation), View (Sort, Columns), References (New, Merge, Delete), and Tools (Format Bibliography, Generate Packet). Beneath the menu bar, a fixed toolbar hosts 16x16 pixel icon buttons with explicit, raised CSS borders, providing immediate access to primary actions. To ensure exact integration across existing applications, the global Archive Explorer receives matching toolbar actions. While browsing the archive, users are presented with identical iconography for "Add to Desk" and "Copy Citation," creating a cohesive, cross-application workflow.

Workflows: Capture, Integration, and Assembly

The utility of the Citation Desk depends entirely on the friction required to populate it. Researchers must be able to collect evidence organically while navigating the broader Archival Reconstruction environment.

Capture Mechanisms and Annotations

• "Copy Citation" Workflow: Located in the Archive Explorer's toolbar, this action invokes the local formatting engine in a background web worker. It generates a plain-text citation of the current document and places it on the system clipboard using the standard navigator.clipboard.writeText() API. Concurrently, it silently adds the structured CSL JSON record to the Citation Desk's local basket, bridging immediate clipboard needs with long-term collection.
• "Add to Citation Desk" Workflow: A discrete button that purely stages the document's metadata in the local workspace without affecting the clipboard, allowing rapid, uninterrupted bookmarking.
• "Add Quote to Packet" Workflow: When a user highlights text within a document in the Archive Explorer, a contextual tooltip appears. Selecting this action captures the highlighted text, the precise page identity, the surrounding contextual paragraph (for provenance checking), and the document's stable URL. This data is serialized and sent to the Citation Desk, where it is stored as a child object linked to the parent citation.
• Integration with Annotations and Research Trails: The existing annotation system is tightly coupled to the Citation Desk. Annotations made on the archival document view automatically pipe into the Context Viewer pane of the corresponding citation. Furthermore, the application's Research Trails feature—which logs the breadcrumbs of a user's navigation through the archive—is serialized and attached to the citation object. This preserves the provenance of discovery, allowing researchers to recall exactly which search query or linking document led them to the cited artifact.

Ordering, Grouping, and Deduplication

As researchers collect data over multiple sessions, duplicate records inevitably accumulate. Zotero's duplicate detection algorithms provide the benchmark for this system, relying heavily on title and author heuristic matching when exact identifiers are absent4. The Citation Desk implements a rigorous two-tier deduplication check upon import or manual invocation:

1. Tier 1 (Cryptographic Match): The system evaluates the cryptographic checksum of the source artifact and the stable archival URL. If either matches an existing record exactly, the system flags a definitive duplicate.

2. Tier 2 (Heuristic Match): If Tier 1 fails, the system evaluates the title and author fields. Following historical reference manager logic5, if the title matches exactly (ignoring case and punctuation) AND at least one author's last name matches, it is flagged as a potential duplicate.

When duplicates are detected, the UI presents a classic "Merge Items" dialog window. The user is presented with a side-by-side comparison of the conflicting fields and can select a "Master" record while cherry-picking superior metadata from the subordinate record, mirroring Zotero's conflict resolution interface5. Within the workspace, ordering and grouping are managed entirely via IndexedDB queries. Users can create hierarchical folder structures (collections) within a left-hand navigation pane. A single citation can belong to multiple groups simultaneously without duplicating the underlying record in the database, a relational model that prevents metadata divergence across different research projects.

Deterministic Citation Transformation

The core requirement of generating highly formatted outputs locally is achieved through the integration of citeproc-js, a robust, format-independent bibliography tool built for browser environments28. The citeproc-js library is initialized locally, loading CSL (Citation Style Language) XML styles and locales directly from the client bundle. This completely eliminates the need for server-side processing, fulfilling the strict local-only privacy constraint and ensuring deterministic output regardless of network connectivity.

Formatting Recommendations and CSL Justification

The system justifies the use of CSL JSON as its internal storage format because it natively maps to the citeproc-js engine and allows seamless transition between the most demanding academic styles18. The engine supports the following essential formats:

1. Chicago Manual of Style (18th Edition): The 18th edition introduces significant changes, notably the removal of the requirement for the place of publication in books and the endorsement of the singular "they"30. Furthermore, it discourages the use of Ibid. in favor of shortened author-title notes31. Archival manuscript citations in Chicago style heavily rely on the archive, archive\_location, and call-number fields, rendering them as: Author Last, First. "Document Title." Date. Collection Name, Box X, Folder Y. Archive Name. URL.31.

2. MLA (Modern Language Association): Requires precise formatting of the archive name, institutional affiliation, and location, followed by the date accessed33.

3. APA (American Psychological Association): Treats archival materials as unpublished manuscripts. The format relies heavily on brackets to describe the material \[Description of Material\] and requires the collection and repository name33.

4. Generic Bibliography: A plain, human-readable format designed for non-academic intelligence or legal dossiers, focusing strictly on Date, Title, URL, and Hash Identity, stripping away academic punctuation rules in favor of rapid readability.

To handle specific mapping nuances—such as Zotero's historical practice of mapping archiveLocation into a generic "Extra" field because CSL lacked native support—the architecture utilizes modern CSL JSON specifications where archive\_location is explicitly defined17.

The Research Packet Builder

The ultimate deliverable of a research session is not merely a list of citations, but an actionable, synthesized output. The Research Packet Builder is a dedicated module within the Citation Desk that allows users to weave their collected citations, notecards, and personal annotations into a cohesive document.

Packet Structure and Assembly

A standard Research Packet comprises a formalized structure designed to act as a standalone evidentiary document:

• Header: User-defined Title, Date Generated, and a system-generated cryptographic hash of the packet's contents to ensure chain-of-custody.
• User Notes: High-level executive summaries or introductory text written by the researcher, synthesized from the Context Viewer annotations.
• Selected Quotations (The Evidence Body): A chronologically or thematically ordered list of captured quotes. Each quote is followed by a shortened Chicago-style citation, the precise page identity, and a hyperlink back to the stable archive route. Surrounding context is included in smaller, grayed-out text to prove the quote was not selectively edited.
• Bibliography: An appended, strictly formatted reference list of all sources cited in the packet, generated automatically by citeproc-js.

Print CSS and Visual Distinction

The visual requirement mandates that personal work must remain distinguishable from archival source authority. Archival documents printed from the system feature stark, utilitarian formatting with strict provenance watermarks. Conversely, the Research Packet utilizes custom Print CSS (@media print) designed to resemble a classic legal or intelligence dossier.

• The CSS aggressively strips out all application UI elements (toolbars, scrollbars, split-pane borders) using display: none.
• It utilizes page-break-inside: avoid on quotation blocks to ensure evidence is not split across physical pages, preserving readability.
• A distinct visual indicator—such as a heavy double-line header border or a subtle repeating background pattern—is applied via CSS to visually communicate "USER CREATED PACKET" to any downstream consumer of the physical paper.
• The "Print Preview" function is invoked via an in-browser modal that scales an iframe representing the printed output, matching the behavioral expectations of legacy desktop software.

Example Output (Fictional Sample Data)

An exported plain-text Evidence Packet would render locally as follows, showcasing the integration of user notes, citations, and hash identity:

====================================================================== RESEARCH PACKET: Origins of the 'Bluebird' Network Infrastructure GENERATED: 2026-09-01 22:11:08 UTC INTEGRITY HASH: 8f4e3c2b1a9d4f...

USER NOTES: The following excerpts demonstrate the timeline of the initial server deployments before the primary node was relocated. EVIDENCE 1: "The mainframe relocation must be completed prior to the winter freeze, otherwise the subterranean cabling will fracture under thermal stress." \-- Page 4, Section 2\. Source: Smith, John. "Logistics Memo: Operation Bluebird." October 12, 1998\. Central Command Archives, Box 4, Folder 12\. https://archive.local/doc/88392. \[Context: The engineering team submitted this warning after reviewing the geological survey...\] EVIDENCE 2: "Budgetary constraints have forced a reliance on commercial off-the-shelf routing hardware." \-- Page 12, Appendix A. Source: Doe, Jane. "Q3 Financial Audit." November 5, 1998\. Central Command Archives, Box 5, Folder 1\. https://archive.local/doc/88410.

====================================================================== BIBLIOGRAPHY (Chicago 18th Edition)

Doe, Jane. "Q3 Financial Audit." November 5, 1998\. Central Command Archives, Box 5, Folder 1\. Smith, John. "Logistics Memo: Operation Bluebird." October 12, 1998\. Central Command Archives, Box 4, Folder 12\.

Data Portability and Export Strategy

Researchers require standard formats to integrate findings with external institutional tools. The export strategy is strictly local, utilizing JavaScript's Blob API and URL.createObjectURL() to generate files directly in the user's Downloads folder, entirely bypassing server interaction. The Citation Desk supports the following export formats:

1. RIS (.ris): The universal standard for citation exchange. The system accurately maps CSL JSON to RIS tags (e.g., TY \- JOUR, TI \- Title, ER \- ) ensuring lines end with the correct ASCII carriage return and line feed characters as required by the specification20.

2. BibTeX (.bib): Essential for LaTeX-based academic workflows. The system generates BibTeX keys using the standard AuthorYear algorithm8, handling special characters and brackets deterministically.

3. CSL JSON (.json): Supported because it serves as the native internal data structure of the Citation Desk. Exporting raw CSL JSON allows for perfect state restoration if the user later imports the file back into the workstation18.

4. Plain-Text Packet (.txt): A highly portable, human-readable UTF-8 text file containing the fully assembled Research Packet. This format mirrors the simplicity of legacy Netscape bookmark exports, ensuring that data is never locked behind proprietary database schemas.

Privacy, Data Sovereignty, and Error Handling

The architectural mandate is absolute: "All personally assembled citation collections and packets remain in the browser/local workspace." To achieve this, the Citation Desk utilizes the IndexedDB API, a low-level API for client-side storage of significant amounts of structured data. All citations, notecards, groupings, and layout states (e.g., pane widths) are serialized and committed to IndexedDB. The application's Content Security Policy (CSP) restricts XMLHttpRequest and fetch calls. The Citation Desk contains no endpoint routes for POST or PUT operations to the PHP server regarding user collections. When a user imports a previously exported .json or .ris file, the file is read via the HTML5 FileReader API. The data is parsed in memory and committed to IndexedDB. The server is entirely unaware of the transaction.

Error Handling Protocols

Because the application processes data locally, rigorous error handling is required to prevent the browser tab from crashing during heavy operations.

• Parsing Errors: If an imported RIS or BibTeX file contains malformed syntax, the parser wraps the execution in a try...catch block. It silently skips the malformed entry, logs the specific line error to an array, and upon completion, presents a dialogue box detailing exactly which records failed to import, rather than failing the entire batch.
• Storage Quotas: Browsers impose storage limits on IndexedDB. Before executing a large import or saving a massive research packet containing embedded image annotations, the system queries the navigator.storage.estimate() API. If the quota is near capacity, the system triggers a warning prompt advising the user to export and clear older collections.

Keyboard Accessibility and WCAG Compliance

A professional desktop application must be deeply accessible, requiring strict adherence to Web Content Accessibility Guidelines (WCAG) 2.1 AA38 and the Accessible Rich Internet Applications (WAI-ARIA) 1.2 specifications39.

Focus Management and Composite Widgets

The Citation Desk relies heavily on composite widgets (e.g., the Data Grid and the Menu Bar). In WAI-ARIA, managing keyboard focus within these complex elements requires specific techniques to avoid trapping the user's keyboard focus. For the main list of citations (the Data Grid), the system implements the "roving tabindex" technique41.

• The grid container is treated as a single tab stop. When a keyboard user presses Tab, focus lands on the currently active row (which possesses tabindex="0"). All other rows possess tabindex="-1"42.
• When the user presses the ArrowUp or ArrowDown keys, JavaScript dynamically intercepts the event, sets the current row to tabindex="-1", sets the adjacent row to tabindex="0", and calls .focus() on the new row41.
• This is vastly superior for stable DOM lists compared to aria-activedescendant, as it moves actual browser focus, allowing standard CSS :focus-visible outlines to natively render the focus state without complex manual styling41.

For the classic application menu bar (File, Edit, View), the system utilizes role="menubar" and role="menuitem"43. Because drop-down menus often involve dynamic DOM insertion, the menu utilizes aria-activedescendant42.

• The parent menubar retains DOM focus.
• As the user presses arrow keys, the aria-activedescendant attribute on the parent updates to match the id of the logically focused menuitem45.
• Screen readers observe this attribute change and announce the newly highlighted item, while custom CSS (\[aria-activedescendant="id"\]) highlights the menu option41.

Visible Focus Requirements

WCAG 2.1 Level AA mandates that all focus indicators must be highly visible and meet a minimum 3:1 contrast ratio46. The application globally utilizes the :focus-visible pseudo-class to draw a thick, high-contrast outline around active elements, overriding any legacy browser defaults. Furthermore, error states (e.g., attempting to export an empty basket) are handled via standard WAI-ARIA role="alert" live regions, ensuring immediate, non-intrusive screen reader announcements.

Phased Feature Priorities and Acceptance Criteria

To ensure a manageable release cycle for the Archival Reconstruction environment, the Citation Desk will be developed in three deliberate phases.

Phase 1: Core Desktop and Provenance

This phase establishes the foundational local database and UI architecture.

• Features: Split-pane UI layout, IndexedDB local storage scaffolding, Archive Explorer "Copy Citation" integration, basic CSL JSON mapping, and DACS-compliant field extraction.
• Acceptance Criteria:
• A user can select a document in the Archive Explorer, click "Add to Desk", and see it instantly appear in the local Data Grid.
• Disconnecting the network completely does not prevent the user from viewing, editing, or deleting items in the Citation Desk.
• Menu bar supports full keyboard navigation via arrow keys in compliance with WAI-ARIA menubar specifications.

Phase 2: Engine, Assembly, and Deduplication

This phase integrates the formatting logic and quality-of-life tools.

• Features: Integration of citeproc-js, Chicago 18th/MLA/APA style generation, Notecard/Quote capture workflow, Research Trail integration, and the Deduplication algorithm.
• Acceptance Criteria:
• Highlighting text in the Archive Explorer allows adding a "Notecard" child to a citation, complete with captured context.
• Executing deduplication correctly identifies two records with the same Title and Author, prompting the Merge dialog without crashing the browser.
• Generating a bibliography via citeproc-js produces perfectly formatted HTML corresponding to Chicago 18th edition rules, omitting publication place where appropriate.

Phase 3: Export, Portability, and Print

This phase finalized the deliverable outputs.

• Features: Research Packet Builder, Print CSS rendering, and .ris, .bib, and .json local file generation.
• Acceptance Criteria:
• Triggering an export creates a physical file download via Blob generation without any network requests observed in the browser dev tools.
• Printing a Research Packet hides all UI elements, enforces page breaks, and displays the "USER CREATED PACKET" visual distinction.
• Exported RIS and BibTeX files are correctly parsed when imported into standalone Zotero, JabRef, or EndNote applications.

Works cited

1. ProCite 5.0 \- Digital Collections \- University of Michigan, https://quod.lib.umich.edu/j/jahc/3310410.0003.114/--procite-50?rgn=main;view=fulltext

2. Concepts/Reference \- Papyrus, https://www.researchsoftwaredesign.com/ftp/demo7/conref7.pdf

3. Storing Research With Papyrus Author, https://support.papyrusauthor.com/wiki/storing-research-papyrus/

4. Finding & Merging Duplicates in Zotero \- CASRAI, https://casrai.org/guides/finding-and-merging-duplicates-in-zotero

5. Duplicate Detection | Zotero Documentation, https://www.zotero.org/support/duplicate\_detection

6. Reference Types \- EndNote, https://docs.endnote.com/docs/endnote/2025/v1/windows/en/content/17reftypes/ref\_types.htm

7. Manual Manuscript/Archive Style \- EndNote Community, https://community.endnote.com/t/manual-manuscript-archive-style/314880

8. Blog | CiteDrive, https://dev.citedrive.com/es/blog/5/

9. What is a good system for generating BibTeX reference keys?, https://academia.stackexchange.com/questions/43609/what-is-a-good-system-for-generating-bibtex-reference-keys

10. Changelog \- Zettlr, https://www.zettlr.com/changelog

11. (PDF) Describing archives a content standard \- ResearchGate, https://www.researchgate.net/publication/237165735\_Describing\_archives\_a\_content\_standard\_recommendations\_to\_the\_standards\_committee

12. Describing Archives: A Content Standard (DACS), https://www2.archivists.org/groups/technical-subcommittee-on-describing-archives-a-content-standard-dacs/describing-archives-a-content-standard-dacs-second-

13. Describing Archives: A Content Standard, https://saa-ts-dacs.github.io/dacs/dacs.html

14. Introduction and Implementation: MODS User Guidelines, Version 3, https://www.loc.gov/standards/mods/userguide/introduction.html

15. Metadata Object Description Schema (MODS), https://msi.dublincore.org/standards/mods

16. What Is MODS and Why Should You Care? \- Backlog • Archivists, https://www.backlog-archivists.com/blog/mods-metadata

17. CSL 1.0.2 Specification \- Citation Style Language \- Documentation, https://docs.citationstyles.org/en/stable/specification.html

18. CSL data JSON \- citation-style-language/schema · GitHub, https://github.com/citation-style-language/schema/blob/master/schemas/input/csl-data.json

19. Better BibTeX for Zotero \- retorque.re, https://retorque.re/zotero-better-bibtex/index.print.html

20. Ref2RIS: Importing Word-Processed Bibliographies into, https://journal.code4lib.org/articles/6286

21. Introduction to Describing Archival Materials, https://saa-ts-dacs.github.io/dacs/06\_part\_I/01\_introduction\_to\_describing\_archival\_materials.html

22. Describing Archives: A Content Standard \- Wikipedia, https://en.wikipedia.org/wiki/Describing\_Archives:\_A\_Content\_Standard

23. How to Cite Unpublished Work Chicago Style \- GenText AI, https://gentext.ai/guides/en/how-to-cite-unpublished-manuscript-chicago/

24. Best practice for creating citations? \- Question \- forums.tropy.org, https://forums.tropy.org/t/best-practice-for-creating-citations/2148

25. Switch to schema.json for CSL mappings for format=csljson \#134, https://github.com/zotero/dataserver/issues/134

26. Duplicate detection false positives \- Zotero Forums, https://forums.zotero.org/discussion/29350/duplicate-detection-false-positives

27. How to Prevent Duplicate References in Your Library, https://manuelgarcia.info/guides/research/guide/prevent-duplicate-references-reference-library

28. Citation.js: a format-independent, modular bibliography tool ... \- PMC, https://pmc.ncbi.nlm.nih.gov/articles/PMC7924481/

29. (PDF) Citation.js: a format-independent, modular bibliography tool, https://www.researchgate.net/publication/330173589\_Citationjs\_a\_format-independent\_modular\_bibliography\_tool\_for\_the\_browser\_and\_command\_line

30. 5 changes you need to know in the new Chicago Manual of Style, https://news.uchicago.edu/story/5-changes-you-need-know-new-chicago-manual-style

31. Chicago Manual of Style 18th Edition \- Purdue OWL, https://owl.purdue.edu/owl/research\_and\_citation/chicago\_manual\_18th\_edition/cmos\_formatting\_and\_style\_guide/chicago\_manual\_of\_style\_18th\_edition.html

32. Chicago | Getting Started with Primary Sources | Teachers | Programs, https://www.loc.gov/programs/teachers/getting-started-with-primary-sources/citing/chicago/

33. How do I cite archival sources? \- FAQs \- LibAnswers, https://libanswers.usc.edu/faq/90617

34. How to reference a Archive material in MLA style \- Cite This For Me, https://www.citethisforme.com/citation-generator/mla/how-to-cite-a-archive-material

35. Extra fields :: Better BibTeX for Zotero \- retorque.re, https://retorque.re/zotero-better-bibtex/exporting/extra-fields/

36. RIS (file format) \- Wikipedia, https://en.wikipedia.org/wiki/RIS\_(file\_format)

37. LaTeX/Bibliography Management \- Wikibooks, open books for an, https://en.wikibooks.org/wiki/LaTeX/Bibliography\_Management

38. Core Accessibility API Mappings 1.2 \- W3C, https://www.w3.org/TR/2018/WD-core-aam-1.2-20180719/

39. Accessible Rich Internet Applications (WAI-ARIA) 1.3 \- W3C, https://www.w3.org/TR/wai-aria-1.3/

40. Accessible Rich Internet Applications (WAI-ARIA) 1.2 \- W3C, https://www.w3.org/TR/wai-aria-1.2/

41. Keyboard Navigation Patterns for Charts | IDV Guide, https://www.interactive-data-visualization.com/accessible-interactive-data-visualization/keyboard-navigation-patterns/

42. Keyboard-navigable JavaScript widgets \- Accessibility | MDN, https://developer.mozilla.org/en-US/docs/Web/Accessibility/Guides/Keyboard-navigable\_JavaScript\_widgets

43. WAI-ARIA 1.2 Cheat Sheet \- DigitalA11Y, https://www.digitala11y.com/wai-aria-1-1-cheat-sheet/

44. WAI-ARIA: Role=Menubar \- DigitalA11Y, https://www.digitala11y.com/menubar-role/

45. ARIA: listbox role \- MDN Web Docs \- Mozilla, https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/listbox\_role

46. Understanding focus indicators for web accessibility \- Finalsite Support, https://www.finalsitesupport.com/hc/en-us/articles/360034889872-Understanding-focus-indicators-for-web-accessibility

47. Designing Custom Focus Indicators | Craft CMS, https://craftcms.com/blog/designing-custom-focus-indicators