Re: Notes re a roadmap to reaching consensus

Hi Folks,

Picking up on the issue severity aspects:

> I understand it is not important for you.   But it may be for someone else.

The issue-severity sub-group went through most of the tests in the WCAG 3 FPWD and, with caveats, thought that it was possible to identify critical issues and (possibly) rank other issues.

That would be on the basis of an aggregate (of expert opinion/experience), with cross-checking against functional needs.

For example: Alt text for a functional image is (typically) going to be more important than a content image, which will be more important than a decorative image with unsuitable alt text.

When you break down the requirements to a lower level that becomes more realistic. Not perfect, but potentially the basis for more a granular ruler.


> you end up making the provisions less technology agnostic and more technology and current interface approach specific

Yes, but we’ve acknowledged we will need a technology specific level, and that could be the level at which we score (or assign severity).


>  if you add contexts - where do you start and end?

Personally, I think context is the best basis for determining issue severity, but my main experience is to conduct this as process after you’ve identified the WCAG issues.

For example, using <h5>s for headings in the footer (after an <h2>) is unlikely to prevent someone doing one of the primary tasks on the website. Not wrapping heading text in heading tags in the main content is a bigger issue.

It would need to be a process where we provide guidance (a bit like WCAG-EM) on selecting tasks/processes and how to determine severity/priority per method/test. I know that selecting tasks could be gamed, but so can selecting pages for a conformance statement.

Kind regards,

-Alastair

--

@alastc / www.nomensa.com<http://www.nomensa.com>