Issue 39

[SteveALee]

For #39

[joshueoconnor]

@SteveALee @lseeman I'm not sure what to do with this? I see the PR but it looks like there was a decision to not add some content? Is that right? Going thru the commits on guidelines/index.html - I don't see the suggested change and think this may be difficult for the group to review. If there is something I'm missing please let me know.

[SteveALee]

@joshueoconner it's all become a mess.

Lisa asked me to add ALL content in issue, Andrew asked me to remove, git asked me to merge it back as I had pushed.

Somehow the process is muddled.

I'll rip it out and start again. But won't be till next week

[joshueoconnor]

@SteveALee Apologies - but I did chuckle - and feel your pain. Yes, for working group review what we would like is the clear draft SC, in place in guidelines/index.html with a PR.

[lseeman]

sorry steve!!
i was confuced... will try and sort it all out on coga call today!

[SteveALee]

@lseeman No problem
@joshueoconnor glad to cheer you up!
The actual change was the 2nd commit
The first commit was sorting out spacing.
I agree it's not easy to figure out from that little lot :)

[SteveALee]

@joshueoconnor it's just the 2 commits now so easier to read.

[patrickhlauke]

"controls amd features" > "controls and features"

[SteveALee]

@patrickhlauke Thank you!

[LJWatson]

This feedback is from @jspellman @patrickhlauke @stevefaulkner @IanPouncey and @LJWatson

We've tried to look at this SC from the point of view of authors and testers. This SC identifies an important set of user needs, and we hope that our comments will help create SCs that meet those needs, by being as usable as possible for both authors and testers.

This SC seems to cover two basic user needs:

1. People must be able to identify critical controls
2. People must be able to find critical controls

We think it would be easier for this SC to focus on the first user need, and for the second user need to be recommended as best practice instead. Partly because the two needs are different, but also because we think one is more difficult to construct into a practical SC.

1. People must be able to identify critical controls

Suggested SC title: Accentuate critical controls

It should be possible for someone to identify a critical control, as opposed to any other type of control in the same document. We wonder whether we can borrow from the Authoring Tool Accessibility Guidelines (ATAG) for this?

ATAG includes this:

"B.4.1.4 Feature Prominence: All accessible content support features are at least as prominent as features related to either invalid markup, syntax errors,

spelling errors or grammar errors."

An accessible content support feature is something like a field for adding an alternative text to an image. ATAG requires that it has the same prominence as other critical features. In other words, it is given greater prominence than non-critical features.

The ATAG definition for "prominence" is this:

"prominence: A heuristic measure of how likely authors are to notice a user interface component in a user interface that they are operating. Prominence is affected by numerous factors, including: the number of navigation steps required, the reading order position, visual properties (e.g. size, spacing, color), and even the modality of use (e.g. mouse vs. keyboard use)."

We think that if this SC was focused on this single requirement, it would be possible for authors to implement, and practical for testers to assess, whilst addressing a clear user need.

2. People must be able to find critical controls

This is the part we think might be better as best practice. The current SC proposal requires that critical controls are presented "above the fold". This phrase comes from the newspaper industry, and it refers to content that would be visible even when the paper was folded up on a newstand.

The fold was a popular term on the web until about 10 years ago when it became almost impossible to determine exactly where the fold might be. A piece of 2015 research by Luke Wroblewski shows just how many variations there are. With apologies, the data in that article is in an image.

It might be argued that a common set of screen sizes could be identified for testing, but this would be impossible to do in a maintainable way. For example, there are currently five resolutions of iOS devices available, each with two screen orientations. Let's say there are another 10 standard sizes of Android device, also with two screen orientations, and you already have 30 common screen sizes to test. When you include desktops (with average screen sizes from 21" to 27"), laptops (with average screen sizes from 12" to 17"), and then recall that the browser window can be resized on both desktops and laptops, it's become an impossible task.

Even if it were possible to reduce the list of common screen sizes to something more manageable, it would be necessary to revise and update the list every few months. The mobile space regularly produces new screen sizes, wearable devices are growing in popularity, and desktop monitors continue to increase in size (with 34" monitors now on the market) for example.

So we're struggling to understand how authors could meet this SC, and how testers would be able to verify that it had been successfully met. Sites that meet the requirements at the time they were developed could fail 6 months later if the list of common screen sizes was revised. If we've missed something, please help us understand how we as authors and testers can really use this part of the current SC?
If our suggestion makes sense, we're happy to adjust the SC text accordingly and create a new Pull Request (PR).

[SteveALee]

Léonie Thank you for a very clear and well thought out critique. I agree the 2 parts are entwined in the SC as it stands, though in reality it might be argued you need to find them in order to be able identify them. :) So we are agreed to part 1. Good. The issue seems to be mainly with the terminology of the "fold"! I agree it is not really helpful visually and I assume not at all for screen reader access which is predominately serial anyway. It occurs to me that the intention might be that critical controls should be "reachable" without scrolling. But I guess that really boils down to much the same thing. The issue I see with needing to scroll is that functionality can be hidden. It seems to be a common practice to assume the user is aware that vertical scrolling is a common UI pattern. No doubt many users of small format devices are familiar with that, but what of people only used to desktops? Keyboard and tab users will find them, but pointer and touch (speech) users need to scroll to get to them which is a separate and distinct action. Perhaps we should be saying that the presence of any visually hidden and critical controls is clearly signposted? Couldn't that be tested and so included in the SC - assuming "Critical" is testable. thanks again for great input. Steve Lee OpenDirective http://opendirective.com

…

On 14 February 2017 at 17:23, Léonie Watson ***@***.***> wrote: This feedback is from @jspellman @patrickhlauke @stevefaulkner @IanPouncey and @LJWatson We've tried to look at this SC from the point of view of authors and testers. This SC identifies an important set of user needs, and we hope that our comments will help create SCs that meet those needs, by being as usable as possible for both authors and testers. This SC seems to cover two basic user needs: People must be able to identify critical controls People must be able to find critical controls We think it would be easier for this SC to focus on the first user need, and for the second user need to be recommended as best practice instead. Partly because the two needs are different, but also because we think one is more difficult to construct into a practical SC. People must be able to identify critical controls Suggested SC title: Accentuate critical controls It should be possible for someone to identify a critical control, as opposed to any other type of control in the same document. We wonder whether we can borrow from the Authoring Tool Accessibility Guidelines (ATAG) for this? ATAG includes this: "B.4.1.4 Feature Prominence: All accessible content support features are at least as prominent as features related to either invalid markup, syntax errors, spelling errors or grammar errors." An accessible content support feature is something like a field for adding an alternative text to an image. ATAG requires that it has the same prominence as other critical features. In other words, it is given greater prominence than non-critical features. The ATAG definition for "prominence" is this: "prominence: A heuristic measure of how likely authors are to notice a user interface component in a user interface that they are operating. Prominence is affected by numerous factors, including: the number of navigation steps required, the reading order position, visual properties (e.g. size, spacing, color), and even the modality of use (e.g. mouse vs. keyboard use)." We think that if this SC was focused on this single requirement, it would be possible for authors to implement, and practical for testers to assess, whilst addressing a clear user need. People must be able to find critical controls This is the part we think might be better as best practice. The current SC proposal requires that critical controls are presented "above the fold". This phrase comes from the newspaper industry, and it refers to content that would be visible even when the paper was folded up on a newstand. The fold was a popular term on the web until about 10 years ago when it became almost impossible to determine exactly where the fold might be. A piece of 2015 research by Luke Wroblewski shows just how many variations there are. With apologies, the data in that article is in an image. It might be argued that a common set of screen sizes could be identified for testing, but this would be impossible to do in a maintainable way. For example, there are currently five resolutions of iOS devices available, each with two screen orientations. Let's say there are another 10 standard sizes of Android device, also with two screen orientations, and you already have 30 common screen sizes to test. When you include desktops (with average screen sizes from 21" to 27"), laptops (with average screen sizes from 12" to 17"), and then recall that the browser window can be resized on both desktops and laptops, it's become an impossible task. Even if it were possible to reduce the list of common screen sizes to something more manageable, it would be necessary to revise and update the list every few months. The mobile space regularly produces new screen sizes, wearable devices are growing in popularity, and desktop monitors continue to increase in size (with 34" monitors now on the market) for example. So we're struggling to understand how authors could meet this SC, and how testers would be able to verify that it had been successfully met. Sites that meet the requirements at the time they were developed could fail 6 months later if the list of common screen sizes was revised. If we've missed something, please help us understand how we as authors and testers can really use this part of the current SC? If our suggestion makes sense, we're happy to adjust the SC text accordingly and create a new Pull Request (PR). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[alastc]

The issue I see with needing to scroll is that functionality can be hidden.

Depending on screen size, some things will have to be hidden. Whether it is due to scrolling, or because controls have been put behind a menu / drop-down / pop-up / dialogue. There are many methods!

The "fold" as a concept for an SC is a non-starter, one of the images from that link was an overlay of the screen sizes from recent devices:

Which fold would you suggest?

Given the other methods of hiding controls, I was thinking about how to generalise the SC to cover other methods.

I wondered if this would be a possible alternative:

Critical controls or important information are prioritised.

The text from ATAG is a very useful point (and I had forgotten that one - it's been a while!), but the aim there was to make accessibility features prominent compared to certain others, it was not concerned with working out what was important in the first place.

Prioritising content and controls is one of the primary aims of design, or at least any kind of usable design.

The whole point of a UX design process is to understand the users tasks, and prioritise parts of the interface to make the task easier. I cannot see how a guideline can help with this, it is solved by the design process, any guideline will be too simple to apply across homepages, articles, email, IDEs, medical exams etc etc.

When you go down this line of thinking it does not end up with a guideline.

Is there another direction that would be better? Is it mostly about scrolling, or rather, remembering to scroll? Would a browser widget/extension that highlights when there is more to see be a better solution to this problem? (And don't use a Mac which hides scroll bars!?!)

[SteveALee]

I think we are agreed fold is not a useful concept and the intention of SC is to ensure that all controls critical for a given task should be easy to locate (find and identify). I quite agree there are many ways that controls can become hard to locate (who said 'hamburger!) and yes this is largely a design issue.

The whole point of a UX design process is to understand the users tasks,

and prioritise parts of the interface to make the task easier. I cannot see how a guideline can help with this, it is solved by the design process, any guideline will be too simple to apply across homepages, articles, email, IDEs, medical exams etc etc. Oh yes, indeed. And it should be the task a user wants to perform, not the designer want's them to perform! :) But isn't that exactly what WCAG is all about. Some aspects of design (accessibility) are often left out unless we remind designers what should be considered for true inclusive design? I don't agree SCs should be divorced from design aspects. That is impossible even though it is very hard to not be prescriptive and disappear down a rat hole. Accessibility is always closely related to design, not a distinct add-on. For example contrast is an accessibility feature but choice of colours is firmly a design decision. We don't say we couldn't possible say what colours as designer can use so can't specify contrast ratios required for accessibility. We need to find equivalent acceptable techniques for coga, which makes life harder by moving the overlap between a11y and design closer to the design end of spectrum away from more technical issues. But back to this specific SCR.

Is there another direction that would be better? Is it really just about

scrolling, or rather, remembering to scroll? I'm not sure on the intentions of SCs and guidelines and how broad or narrow they need to be. We want to clearly signpost that critical controls are easy to locate and that is obviously not just about scrolling as you highlight above. It's largely a matter of not having to perform another possibly non-obvious action to get to a critical control. But scrolling is one specific issue that could be addressed in an SC or guideline. Perhaps being hidden from immediate view is issue (for visual users). I assume guidelines are external documents that are non-normative? If so how much weight / impact do they carry? This SC addresses a very important point and I don't think it should be pushed off to one side. I Like any accessibility issue - it's an issue that impacts everyone - see https://abookapart.com/products/design-for-real-life

Would a browser widget/extension that highlights when there is more to

see be a better solution to this problem? (And don't use a Mac which hides scroll bars!?!) Unfortunately that brings us back to the old discussion about should accessibility be included or left to AT to sort out. The fact WCAG exists indicates to me we want to help designers embed inclusive design into what they produce produce. So we should address in a SC or guideline (Linux desktops also do that horrid hide scroll bars thing to) So I propose 1) change this SC so that it addresses "People must be able to identify critical controls" 2) We split out the discoverability of critical controls to a new SC or quideline. I'm slightly reticent to do so and finding and identifying are very closely related. But We need to get SOMEHTING into wcag 2.1 Steve Lee OpenDirective http://opendirective.com

…

On 15 February 2017 at 00:42, Alastair Campbell ***@***.***> wrote: The issue I see with needing to scroll is that functionality can be hidden. Depending on screen size, some things will have to be hidden. Whether it is due to scrolling, or because controls have been put behind a menu / drop-down / pop-up / dialogue. There are many methods! The "fold" as a concept for an SC is a non-starter, one of the images from that link was an overlay of the screen sizes from recent devices: [image: a maze of overlapping rectangles.] <https://camo.githubusercontent.com/35ba48fea3e345e71d98c312046733e8d8918437/68747470733a2f2f7062732e7477696d672e636f6d2f6d656469612f4234575564776c4351414575306d642e706e67> Which fold would you suggest? Given the other methods of hiding controls, I was thinking about how to generalise the SC to cover other methods. I wondered if this would be a possible alternative: Critical controls or important information are prioritised. The text from ATAG is a very useful point (and I had forgotten that one - it's been a while!), but the aim there was to make accessibility features prominent compared to certain others, it was not concerned with working out what was important in the first place. Prioritising content and controls is one of the primary aims of design, or at least any kind of usable design. The whole point of a UX design process is to understand the users tasks, and prioritise parts of the interface to make the task easier. I cannot see how a guideline can help with this, it is solved by the design process, any guideline will be too simple to apply across homepages, articles, email, IDEs, medical exams etc etc. When you go down this line of thinking it does not end up with a guideline. Is there another direction that would be better? Is it really just about scrolling, or rather, remembering to scroll? Would a browser widget/extension that highlights when there is more to see be a better solution to this problem? (And don't use a Mac which hides scroll bars!?!) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#95 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAlxqhuxronnjjerFEKUMlHW1ZQFMUtUks5rcknYgaJpZM4Ltt_0> .

[alastc]

For example contrast is an accessibility feature but choice of colours is firmly a design decision.

That is a good analogy, but what is the equivalent here?

The SC is trying to influence prioritisation (like colour choice), but there is not a separate attribute (like contrast) to focus on from an accessibility point of view.

It's largely a matter of not having to perform another possibly non-obvious action to get to a critical control.

If a critical control is hidden then there are business or process issues preventing it from being shown. Hiding critical controls means either:

1. There is a lack of understanding of the task(s) users are trying to perform and/or a lack of design ability.
2. There is a business reason to make that task harder (e.g. they want to minimise the number of people doing something).

In the first case: how can a tester know more than the people who designed it? Applying a guideline does not help if you don't know the answer in the first place!
In the second case: an accessibility guideline is not going to influence their decision.

I assume guidelines are external documents that are non-normative?

Sorry, I mean guideline in the general sense of a concept you can apply to any design. In this case it is the Success Criteria.

This SC addresses a very important point and I don't think it should be pushed off to one side.

It is an important point, but is it something that can be addressed by an accessibility guideline?
Everything I've read about it so far (and coming from a design, development and testing point of view) leads me to believe it is best addressed by understanding the tasks users are trying to achieve, and designing appropriately.

Like any accessibility issue - it's an issue that impacts everyone - see
https://abookapart.com/products/design-for-real-life

Have you read it? It is all about dealing with things as part of a UX process, not applying guidelines.

They recommend:

• Challenging your design with niche use-cases;
• Find what matters to users, not you;
• Prioritising stress cases (an identifiable topic you can separate from general usability);
• Meet your users;
• Strengthen your process;

These are all things that are driven by the context of the website and users, there is no one-size fits all solution.

One guideline (SC) you could pull out of that book is to allow text entry for gender questions, so that is an example of going from usability process to a specific criteria you can apply generally. I don't see an equivalent here that we can use.

For example, what is a critical control on the BBC Homepage? (And notice how the menu adapts at different screen widths, does it pass at bigger sizes and fail at smaller sizes?).
Same for the Facebook homepage, Yahoo, Gov.uk, my blog... it is not universally applicable and I can't see a way to reduce the scope to make it applicable.

The fundamental point is that this SC cannot be tested by a guideline, it needs to be addressed by a whole process, and that is not something that the WCAG 2.x framework can tackle.

The two routes forward I see are:

• WCAG 3.0
• A WCAG AA+ denomination (as Lisa suggested) which groups together the process-oriented 'recomendations'.

[SteveALee]

The SC is trying to influence prioritisation (like colour choice), but

there is not a separate attribute (like contrast) to focus on from an accessibility point of view. I'd love to uncover such an attribute. But as you mention below one-size-fits-one with coga (well, all UX including a11y). With contrast we are fortunate in statistically there is a technical aspect of vision that we can pull out to make testable. That's much harder with coga, but still might be possible.

Sorry, I mean guideline in the general sense of a concept you can apply

to any design. In this case it is the Success Criteria Leonie mentioned a "guideline" as being something distinct from the SC which could be used for the 'finding' aspect. Is there such a thing? If so should we consider it as an option?

If a critical control is hidden then there are business or process issues

preventing it from being shown. Hiding critical controls means either: perhaps we need to make a distinction between the set of tasks a user might want to perform (out of scope) and the critical controls within a task the user has decided to engage with (in scope).

Everything I've read about it so far (and coming from a design,

development and testing point of view) leads me to believe it is best addressed by understanding the tasks users are trying to achieve, and designing appropriately. I agree for "which" controls are deemed critical by the user or designer. But not the principle that they should be easy to find in the case the user has started on an activity.

Have you read it? It is all about dealing with things as part of a *UX

process*, not applying *guidelines* Yes. And I have spare copy if anyone wants it. Isn't wcag designed to be embedded in a UX design process of iteratively applying guidelines in the context of a larger scheme?

there is no one-size fits all solution

+1000 But with SCs we have to attempt to extract general principles that can be measured and tested - no? That's the tension we face head on

For example, what is a critical control on the BBC Homepage? ([snip] it

is not universally applicable and I can't see a way to reduce the scope to make it applicable. Again the SC is not trying to identify the critical controls (or tasks they related to) but to say they should be easy to identify (no discussion on this) and find (what we are discussing) So how about * This SC - *Critical controls *and important information required to carry out a specific activity are accentuated in the main modality of the content so they are easy to identify (note I added the concept of an activity). * New guideline / SC - *Critical controls *and important information required to carry out a specific activity *should* be discoverable without scrolling or otherwise uncovering hidden content. Exception being if user is clearly guided to uncovering the critical controls as part of the activity.

A WCAG AA+ denomination (as Lisa suggested) which groups together the

process-oriented 'recomendations'. Sorry, I don't follow. Do you mean a new WCAG AA+ SC for grouping? Where is Lisa's suggestion on this Steve Lee OpenDirective http://opendirective.com

…

On 15 February 2017 at 10:18, Alastair Campbell ***@***.***> wrote: For example contrast is an accessibility feature but choice of colours is firmly a design decision. That is a good analogy, but what is the equivalent here? The SC is trying to influence prioritisation (like colour choice), but there is not a separate attribute (like contrast) to focus on from an accessibility point of view. It's largely a matter of not having to perform another possibly non-obvious action to get to a critical control. If a critical control is hidden then there are business or process issues preventing it from being shown. Hiding critical controls means either: 1. There is a lack of understanding of the task(s) users are trying to perform and/or a lack of design ability. 2. There is a business reason to make that task harder (e.g. they want to minimise the number of people doing something). In the first case: how can a tester know more than the people who designed it? In the second case: an accessibility guideline is not going to influence their decision. I assume guidelines are external documents that are non-normative? Sorry, I mean guideline in the general sense of a concept you can apply to any design. In this case it is the Success Criteria. This SC addresses a very important point and I don't think it should be pushed off to one side. It is an important point, but is it something that can be addressed by an accessibility guideline? Everything I've read about it so far (and coming from a design, development and testing point of view) leads me to believe it is best addressed by understanding the tasks users are trying to achieve, and designing appropriately. Like any accessibility issue - it's an issue that impacts everyone - see https://abookapart.com/products/design-for-real-life Have you read it? It is all about dealing with things as part of a *UX process*, not applying *guidelines*. They recommend: - Challenging your design with niche use-cases; - Find what matters to users, not you; - Prioritising stress cases (an identifiable topic you can separate from general usability); - Meet your users; - Strengthen your process; These are all things that are driven by the context of the website and users, there is no one-size fits all solution. One guideline (SC) you could pull out of that book is to allow text entry for gender questions, so that is an example of going from usability process to a specific criteria you can apply generally. I don't see an equivalent here that we can use. For example, what is a critical control on the BBC Homepage? (And notice how the menu adapts at different screen widths, does it pass at bigger sizes and fail at smaller sizes?). Same for the Facebook homepage, Yahoo, Gov.uk, my blog... it is not universally applicable and I can't see a way to reduce the scope to make it applicable. The fundamental point is that this SC cannot be tested by a guideline, it needs to be addressed by a whole process, and that is not something that the WCAG 2.x framework can tackle. The two routes forward I see are: - WCAG 3.0 - A WCAG AA+ denomination (as Lisa suggested) which groups together the process-oriented 'recomendations'. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#95 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAlxqq7Ca99y-8U8YPTAMSx9YyYxR4-bks5rctEPgaJpZM4Ltt_0> .

[lseeman]

@jspellman @patrickhlauke @stevefaulkner @IanPouncey and @LJWatson @alastc
Folks, are you all aware that we defined above the fold?

• positioned in the upper part of a web page and so visible without scrolling down the page in the main modality of the content.
  and we defined the main modality of the content as modalities that were considored at design time. ut is kind of like a baseline which is a concept we already have.

Unfortunatly many designers feel that "dsicoverability " makes the experence more engaging. That is the business case why people are making it harder to use the content :(

[lseeman]

I am comfortable with * This SC -
*Critical controls *and important information required to carry out a specific activity are accentuated in the main modality of the content so they are easy to identify unless doing so will interfere with the main function of the content (such as a game).

And we add scrolling and covered information as a failure techneque

[SteveALee]

Great what is "failure technique" and where does it live? In a bullet point in the SC? Steve Lee OpenDirective http://opendirective.com

…

On 15 February 2017 at 13:49, Lisa Seeman ***@***.***> wrote: I am comfortable with * This SC - *Critical controls *and important information required to carry out a specific activity are accentuated in the main modality of the content so they are easy to identify unless doing so will interfere with the main function of the content (such as a game). And we add scrolling and covered information as a failure techneque — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#95 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAlxqnOZDNo4zF3_8kirQscHk-Jt9xZ2ks5rcwJegaJpZM4Ltt_0> .

[stevefaulkner]

Folks, are you all aware that we defined above the fold?

I suggest that defining something which has no practical meaning, due to the proliferation of viewport sizes, viewport orientations, screen resolutions and potential user customization of content (zoom to 300%, for example) and is not helpful and will not be helpful to people trying to implement it or people using the end product. I suggest it is better to remove discredited terminology.

[alastc]

Folks, are you all aware that we defined above the fold?

Yes, but definition doesn't help. We (and most of our clients) design sites where the 'main modality' is everything from 320px wide phone to a 3000px wide desktop. There still isn't "a" fold, or even a "main modality" really, one of the points of web design is that it applies across many devices & modalities.

*Critical controls *and important information required to carry out a specific activity

This is still impossible to assess, what is critical? and what counts as a specific activities?

I've tried (conceptually) to apply this to common/popular sites and I can't see how you would pass/fail something. E.g. BBC, Facebook, Yahoo, a blog, Word online, etc.

what is "failure technique" and where does it live? In a bullet point in the SC?

Techniques/failures are the detailed methods you use to pass an SC, or recognised (and universal) failures for an SC. For example.

I'm not concerned by having techniques, they just need to be theoretically possible at this stage.

The substantive issue is that it does not appear possible apply this to many web pages.

many designers feel that "dsicoverability " makes the experence more engaging.

Are there some really awful examples of this you can point me to? Perhaps there is another angle.

[jspellman]

many designers feel that "dsicoverability " makes the experence more engaging.

Are there some really awful examples of this you can point me to? Perhaps there is another angle.

Alastair, I was suggesting that we approach this problem by adapting the ATAG definition of Prominence. Mike Pluke disagreed and wanted to use the EN301 definition, but that only gives equal discoverability, not better discoverability. He also thought Prominence was untestable, but I disagreed, since the definition is a comparison with other components. It's not easily testable, but I think it could be automated, especially if we were more specific than ATAG and listed the ways that prominence could be compared.

[lseeman]

I can think of many examples. I do not want to point to them and offend the people involved All the best Lisa Seeman LinkedIn, Twitter

…

---- On Wed, 15 Feb 2017 20:22:07 +0200 jspellman<[email protected]> wrote ---- many designers feel that "dsicoverability " makes the experence more engaging. Are there some really awful examples of this you can point me to? Perhaps there is another angle. Alastair, I was suggesting that we approach this problem by adapting the ATAG definition of Prominence. Mike Pluke disagreed and wanted to use the EN301 definition, but that only gives equal discoverability, not better discoverability. He also thought Prominence was untestable, but I disagreed, since the definition is a comparison with other components. It's not easily testable, but I think it could be automated, especially if we were more specific than ATAG and listed the ways that prominence could be compared. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[alastc]

@jspellman if it was just about prominence I would agree, the issue is about what should be prominent.

ATAG was using it to provide equal priority for accessibility specify functions compared to other specified functions.

For this SC there would have to be a method of saying what is critical / important.

If the site hasn't done that already via a UX process, how do you apply the guideline?

@lseeman you have my email address if you'd like to spare people's blushes.

[awkawk]

Closing this pull request as it is very much overcome by other changes in the spec.