Re: Content yet to be written for Capabilities

No problem. Sounds like yet another clarification for the Introduction.

Jason Taylor writes:
> Hi
> 
> To be honest I read all the source areas and couldn???t understand this was the purpose. In short you can do it at source by following the WCAG . We should discuss what ???source??? was intended to capture/communicate as I wasn???t involved at that time .
> 
> J
> 
> 
> This e-mail and any accompanying attachments are intended only to be read or used by the named addressee(s). It is confidential and contains legally privileged information. If you have received this message in error, please notify the sender immediately and delete this message.
> 
> Sent from my iPhone
> 
> On Apr 18, 2024, at 11:48???AM, Janina Sajka <janina@rednote.net> wrote:
> 
> ???Awesome, Jason, thanks! Will get this into our doc in the next couple
> days.
> 
> 
> One observation -- You don't discuss the opportunity to do any of these
> at source. We left that in our analysis in order to be comprehensive.
> 
> But, we discovered another reason to do these things apart from source
> in the process, the ability to provide consistency in the UI.
> 
> 
> Jason Taylor writes:
> Hi Janina
> 
> I have focused on missing content under the functionality section. I believe the automaticity status benefits from adding a little color behind each so o included that too.
> 
> Hoping here on email is fine for you .
> 
> 
> 
> 5.6 Client-Side Interactions
> 
> 
> 5.6.1 Managing Time Outs
> 
> 
> Source: Client-side scripts often control session time-outs to manage server load and security. However, not all scripts are designed with accessibility in mind, which can inadvertently lock out users who need more time to interact with web content.
> 
> 
> Trade-offs: While time-outs are necessary for security and efficient resource use, they can disproportionately affect users with disabilities who require more time to read and interact with content. Extending time limits or allowing users to request more time can mitigate these issues but might slightly increase the risk of attacks like session hijacking.
> 
> 
> Benefit: Implementing adjustable time-outs on the client side enhances accessibility by allowing users to extend sessions as needed. This flexibility ensures that all users, regardless of their ability to interact quickly, can fully engage with web content without disruption.
> 
> 
> Automatability: In no significant way - While detecting user activity and adjusting timeouts might seem automatable, verifying that these adjustments do not affect user experience negatively or interfere with other scripts without human oversight is challenging. Autonomous systems might struggle with context-specific nuances that require human judgment.
> 
> 
> 5.6.2 Accessible Validation
> 
> 
> Source: Validation of user input on client-side forms is typically handled via JavaScript. This immediate feedback can be made accessible by ensuring that error messages are communicated through assistive technologies.
> 
> 
> Trade-offs: Client-side validation improves user experience by providing instant feedback; however, it must be designed to ensure that error messages and corrective prompts are accessible to all users, including those using screen readers or other assistive technologies.
> 
> 
> Benefit: Accessible client-side validation enhances the form-filling experience for users with disabilities by providing immediate, understandable feedback that assists in error correction without the need for server-side interaction.
> 
> 
> Automatability: In some cases - The automation of client-side validation can often autonomously detect errors, remediate them by providing feedback, and verify the corrections with high reliability. Frameworks and scripts can be designed to handle a wide range of common input errors, making this capability highly automatable.
> 
> 
> 5.6.3 Client-Side Interactions
> 
> 
> 5.6.3.1 Ensure Keyboard Access to Interactive Elements
> 
> 
> Source: Many web applications rely on mouse-driven events, which can exclude users who depend on keyboard navigation due to physical limitations or personal preference.
> 
> 
> Trade-offs: Providing comprehensive keyboard support may require significant restructuring of event handlers in web applications, potentially increasing development time and complexity.
> 
> 
> Benefit: Ensuring keyboard accessibility for all interactive elements significantly improves the usability of web applications for users with motor disabilities and those who prefer keyboard navigation.
> 
> 
> Automatability: In no significant way - Automatically ensuring keyboard access involves modifying event handlers and potentially the DOM structure, which can affect existing page scripts and styles. Autonomous verification of these changes without impacting user experience or other functionalities is not currently feasible.
> 
> 
> 5.6.3.2 Manage Focus Through Interactive Processes
> 
> 
> Source: Focus management is critical in dynamic web applications where elements are constantly updated. Poor focus control can disorient users, particularly those who rely on screen readers.
> 
> 
> Trade-offs: Implementing robust focus management involves complex event handling and state tracking, which can complicate application code.
> 
> 
> Benefit: Proper focus management ensures a smoother navigation experience for all users, allowing them to maintain context and control through dynamic changes.
> 
> 
> Automatability: In some cases - While focus management can be scripted, verifying that automated focus adjustments do not disrupt user experience or interfere with other interactive elements typically exceeds the capabilities of current autonomous systems.
> 
> 
> 5.6.3.3 Handle Dynamic Pages
> 
> 
> Source: Dynamic pages that update without full reloads (using AJAX and similar technologies) pose challenges for users who rely on screen readers, as these users may not be aware of changes on the page.
> 
> 
> Trade-offs: While dynamic updates provide a smoother user experience, they require careful management to ensure that all users are informed of changes in content or state.
> 
> 
> Benefit: Properly managed dynamic pages can offer a seamless experience for all users, including those with disabilities, by providing necessary alerts and updates through assistive technologies.
> 
> 
> Automatability: In some cases - Handling updates on dynamic pages using standard technologies like AJAX and implementing ARIA-live regions can be automated. However, ensuring these updates do not affect other aspects of the page???s functionality often requires human verification.
> 
> 
> 5.6.3.4 Managing Time Outs (Duplicate Section)
> 
> 
> Source: (Refer to section 5.6.1)
> 
> 
> Trade-offs: (Refer to section 5.6.1)
> 
> 
> Benefit: (Refer to section 5.6.1)
> 
> 
> Automatability: (Refer to section 5.6.1)
> 
> 
> 5.6.3.5 Accessible Validation (Duplicate Section
> 
> 
> Source: (Refer to section 5.6.2)
> 
> 
> Trade-offs: (Refer to section 5.6.2)
> 
> 
> Benefit: (Refer to section 5.6.2)
> 
> 
> Automatability: (Refer to section 5.6.2)
> 
> 
> 5.6.4 Custom Components
> 
> 
> 5.6.4.1 Correct Semantic Behavior
> 
> 
> Source: Custom components often deviate from standard HTML elements in terms of functionality and accessibility. Ensuring that these components reflect correct semantic behavior is crucial for accessibility tools like screen readers.
> 
> 
> Trade-offs: Aligning custom components with standard semantic behaviors often requires additional development effort and rigorous testing, especially when components are highly interactive or complex.
> 
> 
> Benefit: When custom components adhere to proper semantics, they enhance the user experience for individuals relying on assistive technologies, making web interactions more intuitive and predictable.
> 
> 
> Automatability: In no significant way - Custom components vary widely in functionality and integration, making it difficult for autonomous systems to apply correct semantics without potential conflicts or errors that could disrupt user experience or other page elements.
> 
> 
> 5.6.4.2 Apply or Adjust ARIA Elements
> 
> 
> Source: Accessible Rich Internet Applications (ARIA) roles and attributes enhance accessibility when native HTML elements cannot fully describe the widget???s function.
> 
> 
> Trade-offs: Incorporating ARIA roles and attributes requires a detailed understanding of ARIA specifications and how assistive technologies interpret these roles. Overuse or incorrect use can lead to more harm than good.
> 
> 
> Benefit: Correct application of ARIA roles enhances the accessibility of web applications by providing users with disabilities the necessary information to interact with various components effectively.
> 
> 
> Automatability: In some cases - While applying standard ARIA roles and attributes can be automated, verifying that these roles do not interact negatively with other attributes or scripts on the page often requires manual oversight.
> 
> 
> 5.6.4.3 Replace Component When Needed With an Accessible Version
> 
> 
> Source: Sometimes, the best solution for accessibility issues in custom components is to replace them with more accessible versions that conform better to standard practices.
> 
> 
> Trade-offs: Replacing components can be costly and time-consuming, particularly if the replacements need to be custom-developed to fit into the existing ecosystem without degrading performance or altering functionality.
> 
> 
> Benefit: Providing an accessible alternative ensures all users have equal access to functionalities, adhering to legal and moral obligations towards inclusivity.
> 
> 
> Automatability: In no significant way - The decision to replace a component involves understanding context, user needs, and the potential impacts on other page elements, which cannot be fully automated without risking significant errors.
> 
> 
> 5.6.5 Textual Affectations
> 
> 
> 5.6.5.1 Drop Cap Implementation
> 
> 
> Source: Drop caps are used to enhance the visual start of a paragraph and can be problematic for screen readers if not implemented correctly.
> 
> 
> Trade-offs: The decorative nature of drop caps might conflict with text clarity and readability for users utilizing text-to-speech technologies unless additional descriptive tags or styles are used.
> 
> 
> Benefit: Properly implemented drop caps can provide both aesthetic value and maintain readability, enhancing the user???s visual and cognitive experience.
> 
> 
> Automatability: In no significant way - Automating the implementation of drop caps that do not disrupt reading devices or other design elements involves nuanced design decisions that currently require human artistic and technical evaluation.
> 
> 
> 5.6.5.2 Bulleted and Numbered Lists
> 
> 
> Source: Lists are fundamental for structuring content but can be problematic if list markers are not recognized by assistive technologies.
> 
> 
> Trade-offs: Ensuring that custom-styled lists are accessible may require overriding default styles, which can complicate design consistency across platforms.
> 
> 
> Benefit: Accessible lists ensure that all users can understand content structure and order, critical for instructions, key points, and navigation cues.
> 
> 
> Automatability: In some cases - Standard list implementations are highly automatable; however, custom styles and interactions with other text or elements may not be autonomously verified for non-interference and accessibility without human input.
> 
> 
> 5.6.5.3 Text Box Framing
> 
> 
> Source: Text box framing involves visually distinguishing text boxes from other elements on the page, which can aid in navigation and readability.
> 
> 
> Trade-offs: Custom frames and borders may need specific management to ensure they do not interfere with text readability or screen reader performance.
> 
> 
> Benefit: Well-implemented text box frames can guide users??? attention effectively and improve the aesthetic and functional usability of the site.
> 
> 
> Automatability: In some cases - While framing can be automatically applied, ensuring that these styles do not clash with other page elements or affect readability requires manual checks, especially with complex layouts.
> 
> 
> 5.6.5.4 Shadow and Outline Effects
> 
> 
> Source: Shadows and outlines are used to enhance text visibility and separateness from the background, crucial for users with visual impairments.
> 
> 
> Trade-offs: Incorrectly implemented shadows or outlines might blur text or create distracting visuals, reducing accessibility.
> 
> 
> Benefit: Properly used shadow and outline effects can significantly improve text legibility, benefiting users with low vision and enhancing overall user experience.
> 
> 
> Automatability: In some cases - Shadows and outlines can be applied autonomously, but verifying their impact on usability and interaction with other visual components typically exceeds the capabilities of current automated systems.
> 
> 
> 5.6.5.5 Text Transparency Control
> 
> 
> Source: Text transparency often serves design aesthetics, such as background text interaction. However, it can render text unreadable for those with visual impairments or in less-than-ideal viewing conditions.
> 
> 
> Trade-offs: Balancing text transparency with legibility can challenge designers aiming to maintain a particular visual style while ensuring content is accessible to users with poor vision.
> 
> 
> Benefit: Proper management of text transparency ensures that all users can read text comfortably, regardless of their visual capabilities, thus enhancing usability and accessibility.
> 
> 
> Automatability: In some cases - Adjusting text transparency can be automated based on background contrast ratios; however, ensuring that these changes do not affect other visual elements or the overall visual integrity of the site often requires human verification.
> 
> 
> 5.6.6 Interactive Text Elements
> 
> 
> Source: Interactive text elements like collapsible lists, tabs, and tooltips enhance web interactivity but can pose significant accessibility challenges if not properly managed.
> 
> 
> Trade-offs: While these features enhance site navigation and aesthetic appeal, they require careful implementation to ensure they do not hinder the accessibility for users with disabilities.
> 
> 
> Benefit: When interactive text elements are accessible, they can greatly enhance the navigational efficiency and user experience, providing all users with equal access to site functionalities.
> 
> 
> Automatability: In no significant way - While interactive elements can be scripted to include accessibility features, autonomously verifying that these scripts do not interfere with other page functionalities or degrade the user experience typically demands manual oversight.
> 
> 
> 5.6.7 Notifications
> 
> 
> Source: Notifications are crucial for real-time information but can be inaccessible if they disappear too quickly or are not announced by screen readers.
> 
> 
> Trade-offs: Designing notifications that are both timely and accessible may require additional considerations, such as user control over timing and the method of dismissal.
> 
> 
> Benefit: Accessible notifications ensure that all users, including those with visual or cognitive disabilities, are aware of important updates and can interact with them appropriately.
> 
> 
> Automatability: In some cases - Notifications can autonomously adjust timings and include accessibility features. However, confirming that these notifications are harmoniously integrated into the overall site design and do not obscure other interactive elements requires human intervention.
> 
> 
> 5.6.8 Authentication
> 
> 
> Source: Authentication processes often rely on visual cues and inputs that can be barriers to users with visual impairments or motor disabilities.
> 
> 
> Trade-offs: Creating fully accessible authentication mechanisms can complicate the design process, potentially increasing development time and costs.
> 
> 
> Benefit: An accessible authentication process ensures that all users can securely access services without undue hardship, aligning with legal standards and ethical practices.
> 
> 
> Automatability: In no significant way - Authentication processes involve complex interactions that are highly sensitive to security requirements. Autonomously adjusting these processes while ensuring they do not compromise other site functionalities or user security is currently beyond the scope of autonomous systems.
> 
> 
> 5.6.9 Rich Media
> 
> 
> Source: Rich media, including video and audio content, enhances user engagement but requires careful management to ensure it is accessible through subtitles, sign language, and audio descriptions.
> 
> 
> Trade-offs: Implementing comprehensive accessible features for rich media can be resource-intensive and requires ongoing commitment to maintain as content updates.
> 
> 
> Benefit: Accessible rich media not only complies with legal requirements but also significantly broadens audience reach and improves user satisfaction.
> 
> 
> Automatability: In some cases - While technologies like automated captioning and audio description are advancing, verifying that these enhancements function correctly across different platforms and do not interfere with other media elements typically requires human involvement.
> 
> 
> 5.6.10 Voice Command
> 
> 
> Source: Voice command technologies facilitate interaction for users with motor and visual impairments but need to be carefully integrated to recognize diverse speech patterns and accents.
> 
> 
> Trade-offs: Ensuring voice command systems are inclusive of all speech variations can be a complex and ongoing challenge.
> 
> 
> Benefit: Well-implemented voice command systems enhance the accessibility and usability of web environments, allowing users to navigate and interact with content hands-free.
> 
> 
> Automatability: In some cases - Voice command technologies require extensive training to handle diverse accents and speech
> 
> ???
> 
> End
> 
> 
> This e-mail and any accompanying attachments are intended only to be read or used by the named addressee(s). It is confidential and contains legally privileged information. If you have received this message in error, please notify the sender immediately and delete this message.
> 
> Sent from my iPhone
> 
> On Apr 17, 2024, at 3:07???PM, Janina Sajka <janina@rednote.net> wrote:
> 
> ???Colleagues:
> 
> Attached to this email is a very dirty web page of the items labeled in Capabilities as
> "yet to be written."
> 
> 
> 
> --
> 
> Janina Sajka (she/her/hers)
> Accessibility Consultant https://linkedin.com/in/jsajka
> 
> The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
> Co-Chair, Accessible Platform Architectures    http://www.w3.org/wai/apa
> 
> Linux Foundation Fellow
> https://www.linuxfoundation.org/board-of-directors-2/
> 
> 
>                                    Glossary
> 
>   EDITOR'S NOTE
>   Section content yet to be written.
> 
> Margin Management
> 
>  Paragraph Indentation
> 
>   EDITOR'S NOTE
>   Section content yet to be written.
> 
> Color
> 
>   EDITOR'S NOTE
>   Section content yet to be written.
> 
>  Drop Cap Implementation
> 
>   EDITOR'S NOTE
>   Section content yet to be written.
> 
>  Bulleted and Numbered Lists
> 
>   EDITOR'S NOTE
>   Section content yet to be written.
> 
>  Text Box Framing
> 
>   EDITOR'S NOTE
>   Section content yet to be written.
> 
>  Shadow and Outline Effects
> 
>   EDITOR'S NOTE
>   Section content yet to be written.
> 
>  Text Transparency Control
> 
>   EDITOR'S NOTE
>   Section content yet to be written.
> 
> Interactive Text Elements
> 
>   EDITOR'S NOTE
>   Section content yet to be written.
> 
> Voice Command
> 
>   EDITOR'S NOTE
>   Section content yet to be written.
> 
> 
> --
> 
> Janina Sajka (she/her/hers)
> Accessibility Consultant https://linkedin.com/in/jsajka
> 
> The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
> Co-Chair, Accessible Platform Architectures    http://www.w3.org/wai/apa
> 
> Linux Foundation Fellow
> https://www.linuxfoundation.org/board-of-directors-2/
> 

-- 

Janina Sajka (she/her/hers)
Accessibility Consultant https://linkedin.com/in/jsajka

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Co-Chair, Accessible Platform Architectures	http://www.w3.org/wai/apa

Linux Foundation Fellow
https://www.linuxfoundation.org/board-of-directors-2/

Received on Thursday, 18 April 2024 17:12:31 UTC