diff --git a/Submissions_SOSE_2026/submissions.md b/Submissions_SOSE_2026/submissions.md
index c3e25bb..499439b 100644
--- a/Submissions_SOSE_2026/submissions.md
+++ b/Submissions_SOSE_2026/submissions.md
@@ -1,91 +1,163 @@
-# Proposal Submission Template — SOSE 2026
-
-> Copy this file, rename it `proposal-team-"mentor's name".md`, and place it in the `Submissions SOSE 2026` folder. Do not raise a PR until your proposal is ready for final review. All the items marked with an asterisk (*) are required.
+# Proposal Submission — SOSE 2026
---
-## Team Details* 👥
+## Team Details 👥
-**Mentor's Name:**
+**Mentor's Name:** Jim Anderson
**Team Members:**
| GitHub Username | Full Name |
|---|---|
-| @username | Full Name |
-| @username | Full Name |
+| @Jextic | Johnny Huynh |
---
-## p5.js Issue* 📋
+## p5.js Issue 📋
-*Details about the first issue assigned to your team.*
+
-- Link to Issue: https://github.com/processing/...
+- **Link to Issue**: [github.com/processing/p5.js/issues/8922](https://github.com/processing/p5.js/issues/8922)
-- Issue Title:
+- **Issue Title**: [p5.js 2.0+ Bug Report]: Loading indication #8922
-- Repository: e.g. p5.js, p5.js-web-editor
+- **Repository**: p5.js
---
-## Abstract* 📝
+## Abstract 📝
-*3–5 sentences. What is the idea, why does it matter, and what do you plan to do?*
+
----
+p5.js has canvas description functions like describe() and describeElement() to generate invisible DOM containers with text that can be read by screen readers. These DOM elements don't have a lang attribute so the TTS engines of the screen readers will be read using the primary voice regardless of the text's language. If the screen reader's voice is defaulted to an English voice and the text is written in a non-English language, the TTS would mangle the pronunciations and produce unintelligible outputs. This could be solved by modifying the describe functions to accept an additional parameter which injects a defined lang attribute into the DOM containers.
-## Problem Statement* 📑
+---
-*What problem are you solving and who is affected by it?*
+## Problem Statement 📑
+
+
+
+Users who rely on screen readers would find this very helpful. After testing sentences in various languages for Windows Narrator and NVDA screen reader, I discovered that sentences without the lang attribute will always use the primary screen reader voice. Oftentimes, the words are hard to understand if the screen reader voice's language is different from the text's language. Additionally, if there is non-Latin text, the screen reader will skip over that block of text entirely if not supported. For example, an English narrator will skip over a sentence written in Kanji or Devanagari. Solving this issue would improve and expand access for international users.
+
+I've also noticed that this is primarily a Windows issue. MacOS VoiceOver has basic Unicode detection so it has the capability of guessing the text's language and switching to the correct narrator although I'm unsure how accurate the macOS VoiceOver usually is. Something to take note of is that if the screen reader doesn't support or doesn't have the language voice installed, it will still use the default voice instead. For the most part, users would already have the voice language that they want already installed and popular screen readers like NVDA already have support for tons of languages.
+
+HTML Test used for Windows Narrator and NVDA:
+```
+
+
+
+
+
+`
+```
+
+I tested this with the English voice as the primary voice. I made sure that the Spanish language/voice pack and Vietnamese language/voice pack were installed for both NVDA and Windows Narrator before testing. The div containers with the lang attribute were successfully switched over to the proper narrator voice while the ones without the lang attribute only used the English voice.
+
+HTML Test in Hindi (Latin and Devanagari):
+```
+
+
+
+
+`
+```
+
+This test was generated with the help of Google Translate so the sentence itself may not be correct. The two tests with the lang attribute were successfully switched over to the Hindi voice narrator. The 1st test was used with the English voice narrator. It sounded ok but if I replaced it with a random longer sentence, it sounds a bit more incomprehensible. After the 2nd test, it immediately skipped over to the 4th test. It was most likely because the English voice doesn't recognize Devanagari and cannot read it so it just skipped and continued at the next detectable sentence.
---
-## Proposed Solution* 💡
+## Proposed Solution 💡
+
+
+
+I propose to update the `describe()` and `describeElement()` functions in `p5.js/src/accessibility/describe.js` to accept an additional parameter which will define the lang attribute. Screen readers can already determine the values of the attribute so abbreviations like 'vi', 'es', 'hi', and 'fr' can be detected as Vietnamese, Spanish, Hindi, and French. The `_describeHTML()` and `_describeElementHTML()` will also be updated accordingly so that it can accept and inject a lang attribute. The lang attribute will be defined if the parameter from the previous functions were also defined. Since an additional parameter is being added to the describe methods, FES would be updated accordingly to let the users know if the lang attribute parameter is invalid. Also, the lang attribute would added to the as part of the DOM so animated sketches (sketches that would call on describe functions repeatedly) would still update the lang attribute correctly. Performance would not be impacted since this would just be setting the lang attribute to an existing element.
-*High-level description of your approach and why you chose it.*
+The parameter will also be optional so that existing p5.js sketches won't be affected. Adding the lang parameter also shouldn't affect existing parameters like `LABEL` or `FALLBACK`. However, there are two approaches I had in mind for the optional lang parameter to coexist with the existing optional display parameter:
+If the user only wanted to set the describe functions to have text and the lang attribute (ignore the display parameter),
+1. The describe functions would simply have a third parameter. In sketches, it would look something like `describe('text', null, 'en')` or `describe('text', undefined, 'en')`. This would look a little awkward but it would be a safer implementation.
+2. The describe functions would be modified so that if the 2nd parameter isn't one of the display parameters, it would be considered a lang attribute instead. There would definitely be ambiguity since display and lang are two different concepts sharing the same parameter.
+
+I was going to consider modifying the functions for textOutput() and gridOutput() to support multilingual screen reader voicing switching as well based on the discussion in [Issue #6992](https://github.com/processing/p5.js/issues/6992), it seems like these two functions might be reworked or removed.
+
+The reference documentations would also be updated to encourage users to write in the native script of their languages instead of the transliteration of that language in Latin characters.
---
-## Research on old issues* 🔭
+## Research on old issues 🔭
+
+
+
+- [Issue #4721: Web accessibility next steps [conversation]](https://github.com/processing/p5.js/issues/4721)
-*If there are existing open issues that align with or validate your proposed idea, reference them here. Your proposal may also help revive or advance work that has stalled. If no directly related issue exists, demonstrate that you have researched the project's backlog by identifying similar or relevant issues. Include links to those issues and briefly explain.*
+This was a conversation of the implementation of describe functions. The author of the issue brought up the question "what should we do about web accessibility in languages other than English". This issue is one of the ways that p5.js could solve to expand language accessibility, especially for visually impaired users.
-## Impact* 🛠️
+- [Issue #6992: Accessibility Features Proposal - Expand Web Accessibility module](https://github.com/processing/p5.js/issues/6992)
-*Select all that apply and add a one-line explanation for each.*
+Issue #6992 focuses more on improving existing accessibility features and covering the WCAG (Web Content Accessibility Guidelines) rules. Adding support for multilingual screen reader voice switching would adhere to [WCAG 3.1.2 Language of Parts](https://www.w3.org/TR/WCAG22/#language-of-parts)
-- [ ] **Feature Implementation** —
-- [ ] **Bug Fix** —
-- [ ] **Performance** —
+---
+
+## Impact 🛠️
+
+
+
+- [x] **Feature Implementation** — Adds an optional lang parameter for describe functions for multilingual screen reader support
+- [ ] **Bug Fix** —
+- [ ] **Performance** —
- [ ] **Scalability** —
-- [ ] **Documentation** —
-- [ ] **Testing** —
+- [X] **Documentation** — Update reference documentation to include a note about using native script instead of transliteration.
+- [X] **Testing** — Add unit test cases to verify that the lang attribute is properly injected into div containers.
- [ ] **Other** —
---
## Inclusivity and Accessibility 🤝
-> Required for proposals that are not bug fixes. If this is a bug fix, write "Not applicable — bug fix".
+
+
+This proposal would satisfy WCAG Criterion 3.1.2 Language of Parts which states that text can be programmatically determined assistive technologies like screen readers. This would help Windows users who use screen readers because without the lang attribute, TTS voices would not be able to detect or switch to the proper language voices.
---
-## Implementation Plan* ⏳
+## Implementation Plan ⏳
+
+
-*Week-by-week breakdown of how you plan to complete the work.*
+Week 1: Refactor describe functions in `p5.js/src/accessibility/describe.js` to accept an additional argument for lang attributes. Also update the HTML generator functions to inject the lang attribute. Test for functionality and create unit cases. Hopefully create a PR at the end of the week.
+
+Week 2: Take into account feedback and add any suggested changes. Finalize the PR.
---
-## Deliverables* 📦
+## Deliverables 📦
-*What will concretely exist at the end of the internship that does not exist today?*
+
----
+After adding the changes, the describe functions will have multilingual support for screen reader voice switching. `describe.js` functions would have support for an additional optional parameter for a lang attribute and the JSDOC reference comments would be updated.
-## Anything Else?
+
-*Anything you'd like maintainers to know that doesn't fit above.*