(This is an evolving document, and feedback is actively sought. Please help us make everyone welcome on this site by sharing feedback via the contact link in the header or on Twitter @literature_geek!)
You are welcome here!
This community seeks readers of every background to join our conversation. Whether you're a first-time reader, enthusiast, a teacher, student, scholar, book club member, or bring another viewpoint to our community, we value your thoughts and invite you to contribute your comments, interpretations, questions, and answers to the novel.
I'm committed to prioritizing universal design for this project and always working toward greater accessibility for this site. This means designing for and testing with a wide variety of readers with differents needs and devices, as well as valuing and encouraging of voices from readers of all backgrounds.
Join us! Yes, you!
No comment or interpretation is too simple—or esoteric. Reading for the first time? Leave questions when you're confused or define a difficult word someone else might not understand. Interested in reading Ulysses from a specific angle (e.g. a feminist reading, or background knowledge about Ireland's political history, or able to translate Latin to English)? Place a short tag on your annotations to help others with similar interests find your thoughts. If you're feeling shy about adding your voice to the site, consider writing for the reader you were before you started the book—I often find that focusing on "helping the past me" is a good way to ignore qualms about whether others can benefit from your thoughts.
Don't hesistate to use the contact link in the header of the site to report abuse or spammers, or make me aware of anyone or thing making you feel unwelcome in this community.
Your feedback on this site's accessibility and inclusiveness is desired
Because I'm designing, coding, and testing this site while negotiating the time and funding constraints of my situation (developing an online community platform while trying to finish a Ph.D.), there will be many tests, features, and bug fixes I'd like to accomplish that I'll need to put off until after my defense; whenever this is the case, though, I'll share the unfinished task on the issues queue for this project's GitHub repository with an "inclusion/use barrier" label so that the need
a) is documented and can be addressed when I have the time, and/or
b) can be addressed by someone else and submitted to my project with a pull request.
I encourage you to share any thoughts you have about improving accessibility (for any of its multiple meanings) on this site, whether that's a feature that doesn't work for you or a request for an enhancement, using the "report an issue" link in the header of the site. You can also use the contact link in the header of the site to make me aware of spammers or others causing problems in the community.
What's been done toward accessibility
Web accessibility is important, and important to me (e.g. I helped develop the Wordpress Braille plugin, and wrote a fix for Joe Dolson's awesome WP Accessibility plugin that was incorporated into the plugin in update 1.2.9). My field (the digital humanities) has only fairly recently begun to address accessibility in our projects, largely through the Accessible Futures and Making Digital Humanities More Open projects. In complex websites like digital editions, there isn't a lot of precedent in terms of accessible design and user-testing, so I've drawn on my background as a web designer as well as how others have made similarly complex, textcentric websites accessible (library catalogue accessiblity work has ported over especially well).
Because of the time restraints imposed by creating this site for a dissertation, some important accessibility work hasn't been accomplished yet (e.g. full keyboard navigation and a page explaining it, testing with a screen reader, options for different color palettes, fonts, and text sizes). These features are important to me, and I'll be making them a priority after I complete my doctoral defense (April 2015). Until then, I've tried to spend any free time on addressing low-hanging fruit. Below is a list of some of the accessibility work I've done on this site:
- The issues queue on this project's GitHub repository offers an "inclusion/use barrier" label to highlight bugs, suggested enhancements, and other tasks for improving this site's accessibility, as a way of prioritizing these issues. Because this is a dissertation project, I may not be able to address an issue before my defense, but I'll keep track of it for when time allows as well as making it public in case someone else would like to submit a fix for the issue.
- Site inspected by the Tenon.io accessibility validator and fixes made from results. 3 issues remain unaddressed.
- Site designed to handle text zoom up to 200% on all pages except book pages.
- Book page zoomability varies by monitor size.
- On a Macbook Air 13" screen with browser in full-screen mode, book pages work up through 125% zoom but not at 150%.
- On a external monitor of fairly normal size (14" x 20"?), book pages work up through 175% but not at 200%. Improving the site design so that all pages function at 200% zoom or below is a priority.
- Site built on the Drupal CMS, which has a community commitment to accessibility.
- Use of em instead of px units in site CSS to support user text-size settings.
- I decided not to grant people roles based on their experience with Ulysses or related subjects—although knowing which users have, for example, taught a class on the novel, I think such designations don't account for the importance of all voices and backgrounds in this community. If you tend to like the annotations and comments you see from a given user, though, you can prioritize their content so that you always see it, or specifically view only their annotations.
- Modules tested and/or used:
- Accessible Skiplinks
- Text Resize/Text Size (after research, opted out of using a module for this; preference seems to be to let the user's device preferences rule and style the page to handle up to 200% size increase)
- More items I haven't had time to list here yet...
What's still to do for better accessibility
- Addressing a bunch of tasks under an "inclusion/use barrier" label in the GitHub repository issues queue for this site
- User-testing beyond what I have a chance to do during the dissertation—with more users, needs, and devices
- Keyboard navigation improvement
- Improve site text-zoom handling from up to 150% to up to 200%
- Creating a better test matrix for accessibility (this article has good recommendations—especially like the plotting of input devices against output devices near the end, but also the overall focus on universal design)
There are also specific pieces of the site that I want to test in various ways, and other notes about potential issues I need to address:
- text fields
- filters/sorts
- dropdowns (single-select, multi-select using ctrl+)
- jQuery sliders (for number/range selection)
- checkboxes
- select all/none
- autosubmit vs. speed/dexterity, time to decide/commit
- page HTML structure (e.g. default of "annotator-h1" class problematic?)
- ... vs. screen reading
- ... vs.complexity of page (use library catalogue usability/accessibility testing research)
- text resizing vs. page resizing (does annotation anchoring break?, collapse sidebars for best fit)
- "mouse bucket challenge": use site start to finish keyboard-only
- moving among devices or between print book and digital site
- bookmarking, filter/sort persistence (set in profile, update on reading page), page refresh vs. global filter persistence; for keeping "place" in book, and for saving, revisiting, or sharing viewed page w/same displayed annotations+highlights (POST vs. GET, timestamping vs. sorts broken by new latest annotations)
- highlight colors and spectrum (for overlapping highlights)
- font type and color; page background color
- language translation
- mobile, tablet use; slow connections (e.g. drop some database queries for better performance when necessary; maybe allow setting this in use profile?)
- touch plugin vs. mobile touch/JS concerns
- older browsers, IE
- Javascript in general (jQuery, AJAX)
- Reasons for not having JS enabled
- Reading speeds: need more granular bookmarking than per page, e.g. per line (either requires messy line divving or nicer: annotation type that shows up on use profile and links to page with just "bookmark" annotation-type text highlighted, so you know where to start again)
- Allow bookmarking of multiple pages (vs. progress bar: people peeking ahead, reading parts offline, jumping around book, losing their place, etc. maybe check for linear completion of chapters, but also give users tracking by total individual pages read or percent w/users allowed to add in pages they read in print book so they get a nice realistic quantifier of how much they've read)
- Friendly to accidental gestures (e.g. click to change what annotations are shown, NOT hover; page flipping; no infinite scrolls)
- AJAX/non-updated URL vs. screen readers (enable GET just for screen readers?)