RE: Issue descriptions library vs. filling reports from scratch

Remembering that accessibility testing differs from functional or systems testing in significant ways if using WCAG … 

 

it’s only by historical accident that accessibility testing is typically lumped in with end-of-life-cycle assurance processes … 

 

that is, the vast majority of testing processes, defect management tools and the descriptors they use are unsuitable for accessibility testing … 

 

severity, for example, as traditionally defined and understood makes little sense (hint: it’s not about user impact).

 

if you can configure your defect management system to accommodate WCAG levels of conformance, a descriptor for the defect scope, a  resolution priority, etc. then much of the data can be filled automatically by selecting a success criterion. 

 

In my experience, requests for such changes are dismissed in organisations given the lowly status of accessibility and it being understood as entirely an assurance step.

 

on a side note, I always find it fascinating that accessibility practitioners have to educate  consumers of defects by including information about who is impacted and the nature of that impact – this isn’t required for any other type of assurance step which goes to the status of accessibility in an organisational hegemony. 

 

 

From: Vlad Kolpakov <vladyslav.kolpakov@gmail.com> 
Sent: Tuesday, July 23, 2024 2:08 AM
To: w3c-wai-ig@w3.org
Subject: Issue descriptions library vs. filling reports from scratch

 

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