diff --git a/Design.md b/Design.md
index 6876e7a..2e46a07 100644
--- a/Design.md
+++ b/Design.md
@@ -15,7 +15,7 @@ The library is designed to be very basic and *not to provide* any more complex e
 There are only very few system events, that are used by the built-in containers and properties accordingly. For you own widgets (i.e. a collection of elements) you can extend the events to include your own events to communicate between elements, effect the control flow and the corresponding generated layouts and much more.
 
 > [!TIP]
-> Keep the tagged type of each user event as small as possible. If you need access to bigger structs you can also aways use pointers.
+> Keep the tagged type of each user event as small as possible. If you need access to bigger structs you can also always use pointers.
 
 This library also provides a rendering pipeline alongside the event loop implementation. Usually the event loop is waiting blocking and will only cause a re-draw (*intermediate mode*) after each event - some events usually don't cause a draw (i.e. `.init` or your own if you want them not to). Even though each frame is regenerated from scratch each render loop, the corresponding application is still pretty performant as the renderer uses a *double buffered* implementation to only apply the changes from each frame to the next to the screen.
 
diff --git a/Roadmap.md b/Roadmap.md
index e04b09b..388b74b 100644
--- a/Roadmap.md
+++ b/Roadmap.md
@@ -67,7 +67,7 @@ The following list contains goals for certain features the library supports or i
           - [x] custom (see example)
           - [x] built-in single line
           - [ ] built-in multi line (**later**)
-          - [x] overflow handling, i.e. where to draw the elipse `..` - left and right
+          - [x] overflow handling, i.e. where to draw the ellipse `..` - left and right
         - [ ] Drop-down menu (`enum`'s)
         - [x] Radio Button (`bool`'s)
         - [ ] Slider (range values)
@@ -111,7 +111,7 @@ The following list contains goals for certain features the library supports or i
     - [x] `Layout`, `Border` and `Rectangle` contain the test cases for rendering of `Container`s
     - [x] `Scrollable` test cases containing inclusion of test creation containing user interaction (i.e. mouse scrolling)
 - [x] Debugging
-  - [x] render correpsonding contents with debug information (the following points are just brain dump of potential information the developer want to see):
+  - [x] render corresponding contents with debug information (the following points are just brain dump of potential information the developer want to see):
 
     Top left corner indicates type of contents (if any) while general information is located in the three remaining corners:
     - [x] *anchor* of `Container`s (top-left corner -> meaning that is the actual `Cell` used for displaying the debug information)
diff --git a/Testing.md b/Testing.md
index fd0aed8..dcf8b6f 100644
--- a/Testing.md
+++ b/Testing.md
@@ -1,6 +1,6 @@
 ## Testing
 
-Using a different testing renderer (in a corresponding namespace `zterm.testing`) renderes without flushing to the screen, but keeps the corresponding `zterm.Cell` slice for comparison. The main question would rather be how to provide the expected value for the `zterm.Cell` slice.
+Using a different testing renderer (in a corresponding namespace `zterm.testing`) renders without flushing to the screen, but keeps the corresponding `zterm.Cell` slice for comparison. The main question would rather be how to provide the expected value for the `zterm.Cell` slice.
 
 The test renderer shall be configured with a given size (as the corresponding terminal for the screen size will not be available). This serves two aspects: Firstly, `.resize` Event triggering and secondly, the rendering into a `zterm.Cell` slice with the provided size dimensions (for testing layout handling and rendering (i.e. of a scrollable element, etc.)).
 
@@ -69,7 +69,7 @@ test "test container against zon file" {
 
 ## Testing user interactivity
 
-When testing with further user interaction the `zterm.testing.expectContainerScreen` function cannot be used. The function creates a *renderer*, *initializes* the provided container and renderes the *screen* for comparison.
+When testing with further user interaction the `zterm.testing.expectContainerScreen` function cannot be used. The function creates a *renderer*, *initializes* the provided container and renders the *screen* for comparison.
 
 This is the implementation of `zterm.testing.expectContainerScreen`:
 
@@ -89,7 +89,7 @@ pub fn expectContainerScreen(size: Size, container: *Container(event.SystemEvent
 ```
 
 > [!TIP]
-> Create serveral *checkpoint screens* that should be tested against when testing for user interaction.
+> Create several *checkpoint screens* that should be tested against when testing for user interaction.
 
 For testing user interaction you need to provide the container with the corresponding *events* it should receive. This includes user key presses, mouse presses (with their corresponding location on the screen), etc. For example see the test for `Scrollable` elements, which create the scrollable `Container` renders it and tests the screen, then scrolls down, re-renders the `Container` to test and finally tries to scroll further down to test for scrolling down after reaching the end of the `Scrollable` element: