Re: Issue descriptions library vs. filling reports from scratch

Hi Vlad,

Short answer - Yes, having a repository of defects and recommendations greatly speeds up the reporting and documentation of the issues you surface.

The way we handle is here is that we have a repository of boilerplate - a defect summary, general recommendation, and who it impacts. Then, if there is any clarification needed we have an additional comments field. For each success criteria we have multiple defect/recommendation/impact choices for the scenarios we commonly encounter. For example, for SC 1.1.1 we have 16 unique combinations covering meaningful or decorative <img>, <svg>, CSS icons, and so on. For example:

"Product image alternative description is not present or does not fully describe the product image.

Describe all the important information from the image about the product. If relevant, include information about color, shape, texture, fabric, style and so on. Use one of the methods in the resource below to provide this text alternative.

Please refer to:
https://www.w3.org/WAI/WCAG21/Techniques/general/G94

People who use screen readers to navigate websites rely on alternative text (alt text) to understand the content of images. If alt text is missing or insufficient, these users will not receive the necessary information about the product image, making it difficult or impossible for them to understand the product being displayed. Individuals with low vision may use screen magnifiers or other assistive technologies to enlarge the content on the screen. In such cases, they may not be able to clearly see the details of a product image and depend on alternative text to comprehend its content. Inadequate or missing alt text would leave them without crucial information about the product. Some individuals with cognitive disabilities or learning difficulties rely on visual cues and descriptions to understand content. If product images are not adequately described, they may struggle to comprehend the product being presented, leading to confusion or frustration."


To this we may add a comment such as "Text alternatives only include the product name. Please include information about the pattern of the product."

Whether you're working from an Excel sheet with vlookups, or manually copy and pasting, a repository of defects will save you a bunch of time, you just have to leave yourself the option to add additional, defect-specific information.

Best,
Juliette


On 7/22/2024 9:14:10 AM, Vlad Kolpakov <vladyslav.kolpakov@gmail.com> wrote:
Hi all!
Arguably, it is more efficient to pull issue descriptions of typical accessibility issues from descriptions library versus filling in every bug report from scratch.
I think that consistency across different projects is an additional benefit, as well as having a shared understanding within the team.  

On the other hand, I see that information in such fields as Summary, Steps, Actual behavior and Expected behavior may differ depending on the context in which the issue was found. Even remediation recommendations will often need to be adapted to a specific project which means additional time for editing. So, I can understand folks who think that writing a bug from scratch may take the same time as finding the same bug in the library and adapting it to the context.
Personally, I'm a boilerplate content fan. But given the above, I'm a bit hesitant whether it is a good idea trying to promote the same approach to the team. :)

Please advise:  in terms of efficiency, does that make sense developing and maintaining the issue descriptions library or not?    
Thanks in advance!

-- Best, Vlad
[179c3fa5-0072-452c-bad0-8961e78f34b5]

Received on Monday, 22 July 2024 16:26:42 UTC