I am in favour of the change but I see this change as part of a larger piece of work to organise buttons with Adapt.

Overview of thoughts:

• Categorise buttons in Adapt into sections and separate them out
  • navigation (nav bar / menu item) / question (submit / feedback / items) / ui (notify / drawer / component) etc
• Normalise styles through out Adapt to introduce consistency
  • Potential use of mixins for each category
• Retain a disabled style
  • Client branding often states specific disabled state styles (default can inherit static state)
• Add disabled button opacity support

Counter arguments:

https://uxmovement.com/buttons/why-you-shouldnt-gray-out-disabled-but
The comments section of the main article provide a good teardown of using faded instead of greyed to represent inactive/disabled buttons.

The main issues appear to be:

• It doesn't solve for partially sighted or visually impaired users as the visual language is still ambiguous
• It doesn't solve the issue of the initial indistinction between an enabled and disabled button when either state is absent
• Greyed buttons are effectively, the standard
• There are other ways of overcoming the confusion of clicking a disabled button accidentally, rather than preventing a click initially
• Faded buttons don't solve the contrast issue

It seems that switching the visual metaphor for representing the disabled state between greyed and faded, retains mostly the same issues.

WCAG contrast requirements on inactive buttons:

https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html#inactive-controls
While the section of the WCAG docs Understanding SC 1.4.11 does say that contrast accessibility requirements have been removed from inactive buttons, it does gives rationale as to why (that it's too difficult to provide a generic solution) and a future direction, both of which do not really support this proposal in spirit (the word inactive also has some contention).

When we consider [aria-disabled] buttons as opposed to [disabled] buttons, the former are unclickable but focusable and readable, the latter are unclickable, unfocusable and unreadable. As such, the [aria-disabled] buttons will still need to be appropriately visible as an accessible UI component, as they are available to screen reader and keyboard accessible users. Meaning we probably should strive for good contrast on disabled buttons where possible.

Unavoidable downsides of faded/greyed:

https://medium.com/@h_locke/is-it-ok-to-grey-out-disabled-buttons-8afa74a0fae
The references in this article discuss at length the different user groups impacted by disabled buttons (SR, various visual impairment, general axioms) and how the different solutions all have unavoidable downsides, mostly on the lines of:

• It doesn't solve for partially sighted or visually impaired users as the visual language is still ambiguous
• It doesn't solve the issue of the initial indistinction between an enabled and disabled button when either state is absent
• If a button isn't disabled it should instead display a warning

With specific reference to contrast on disabled buttons w3c/wcag21#805 and w3c/wcag#922
With specific reference to the Submit button being disabled before interaction fulfillment w3c/wcag#1512 for which we already have https://github.com/adaptlearning/adapt-contrib-instructionError

There are a few suggestions the author has that we've not yet considered:

• Using the disabled mouse cursor on desktops on hover state for disabled buttons.
  
• Using recessing, or inner borders
• Inverting the text colour

I quite like adding the disabled mouse cursor.

Disabling vs hiding:

Advantages of disabling:
Users always find the same control in the same place
Advantages of hiding:
Remove irrelevant items so users can focus on those relevant items, removing noise from the UI.

https://www.smashingmagazine.com/2021/08/frustrating-design-patterns-disabled-buttons/
This doesn't quite encapsulate the issue for me as the advantage and disadvantage seem more relevant for e-commerce sites, as can be seen in the above reference, where there can be many related and changing user interface components. In Adapt we very rarely have so many changeable controls.

Advantages of visible [aria-disabled] buttons:

• Object permanence, Object consistency
• Interaction affordances
• Keyboard and/or screen reader accessible
• Reduced cognitive load

When using a screen reader as a non-sighted user, UI changes, such as when buttons become shown or hidden or rearranged, are not alerted to the user. The unannounced introduction or removal of UI has the potential to disrupt a user's sense of object permanence and their orientation in the material, which introduces unnecessary cognitive load and potential confusion. This can be especially acute when hiding and introducing controls whilst navigating through a list of items.

Secondarily to object permanence, and this applies to sighted users as well, are the possible affordances to a user from an [aria-disabled] button. Narrative back buttons are always initially [aria-disabled], by having an [aria-disabled] back button and an enabled next button, it is possible to infer that; I am at the beginning of a list, I can't go back, I can go forward.

If the narrative back button were initially hidden, it would not be possible for the non-sighted screen reader user to infer that a back button should appear later, that a list is beginning or that the list must be navigated via next/back controls. None of those affordances would be immediately available but they would appear after the user had experienced the first content item, when the back button would be shown and later found. By hiding the back button in this use-case, we'd effectively be teaching the user about the user interface during the essential material and not, as is ideal, before it, where allowing them to learn the UI, then use it to navigate and focus on the content seems the most efficient use of time.

The case of the submit button is much the same as the narrative back button, in both regards. Having it readable+visible but disabled, signifies that it may become enabled. The instruction text, interaction description and UI all hint at the rules for its enablement.

Tooltips:

For best practise (not required by WCAG) to account for usability/accessibility issues, disabled buttons could have a tooltip explaining that its disabled and the reason for the disabled state. Although my feeling is, this could be optional on a project by project basis or not needed at all.

Which disabled buttons would they apply to? Which user-groups would this solve for?

Example:

• It doesn't solve for partially sighted or visually impaired users as the visual language is still ambiguous

For this reason, I think we shouldn't rely on colour alone (or opacity) to distinguish states (to be looked at as part of adaptlearning/adapt-contrib-core#386). For example, we could use the padlock icon for locked disabled buttons. Issue raised here for Tutor but a global approach to locked buttons in Adapt would make sense.

• It doesn't solve the issue of the initial indistinction between an enabled and disabled button when either is absent

I'm in favour of disabling buttons rather than hiding.

• Greyed buttons are effectively, the standard

Although this is true, I think the initial issues raised around needing to theme to any branding/colour palette still needs addressing and many brands do include, clash or too similar to grey. I'd be in favour of having an opacity as a standard disabled state in Adapt. Whilst maintaining flexibility to support more complex styles for those brands where a disabled state is defined in brand guidelines (to be looked at as part of adaptlearning/adapt-contrib-core#386).

@kirsty-hames I like the option of being able to use opacity.

Opacity example:

There's a really good example highlighted in the reference w3c/wcag21#805 (comment) which links directly to the gov.uk disabled button spec https://govuk-elements.herokuapp.com/buttons/#button-disabled .

Gov.uk have only described the one "primary button" style here, with the distinct green etc. They are using disabled="disabled" though, which makes the button unclickable and unfocusable, and recommend an error message to explain why the button is disabled. So this has use-case ambiguity again, the error message cannot be associated with a button click as a button click isn't possible. But, they are definitely not recommending to hide the button.

• use the aria-disabled attribute for older screen readers

Gov.uk's point on using aria-disabled only for older screen readers is a bit wrong for us. So that it's possible to tab to a disabled button (keyboard a11y) and arrow to it (screen reader a11y) and so that it'll read as disabled in all scenarios (keyboard tab + screen reader) and display as disabled with styling, along with javascript to stop any click behaviour, we kind of use aria-disabled as described in this excerpt from mdn article on aria-disabled https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-disabled:

In fairness Gov.uk do go on to explain the two use-cases where they expect a disabled button might be used:

• an example of a useful disabled option is a calendar with greyed out days where no bookings are available
• provide another way for the user to continue, add an error message or text to explain why the button is disabled

Which is an unclickable list item with no children (calendar date with no booking, accordion item with no body, etc) and a continue button that requires further fulfillment (submit button on an mcq, locked menu button, etc).

Icons for disabled state:

For example, we could use the padlock icon for locked disabled buttons.

There are other mentions of using icons to indicate disabled states w3c/wcag21#805 (comment) . The "locked" state of plp, menu items and trickle are particularly good examples where there is a generic icon that represents why the button is disabled. Finding a similar uniform icon for the narrative back and question submit buttons might prove a little more difficult in the same way that trying to write tooltips for them is difficult.

Perhaps something similar to the disabled cursor icon may work?

Icons and tooltips:

Generally I think using tooltips to display disabled state is a cumbersome idea that we shouldn't implement.

Disabled buttons, existing use-cases and recommendations:

All disabled buttons should be aria-disabled=true not disabled="disabled" and have the class is-disabled. The attribute and class allows the button to be styled as disabled and to read in keyboard and screen reader accessibility.

We definitely have some use-cases for disabled buttons now:

• Locked
  • Visually disabled
  • Padlock icon and optional item text
  • Aria should prepend the Locked. globals equivalent to the item text, "unavailable" will be added by the screen reader
• List start/end (can be mixed with next locking)
  • Visually disabled
  • Left and right icon or back and next text
  • Aria should read "Back" or "Next" globals equivalent or otherwise the back and next text button text, "unavailable" will be added by the screen reader
• Form/question submit
  • Visually disabled
  • Submit text and an optional error reiterating the instructions
  • Aria should read the submit text, "unavailable" will be added by the screen reader

"Visually disabled" = greyed / faded, disabled mouse cursor

Current narrative back button:

Current submit button:

@StuartNicholls any thoughts?

I think we just need a pr for the opacity on buttons to resolve this issue? Could we keep greyed as the standard and supply opacity as an option?

The classes alignment (button type groupings), locked icons, disabled mouse cursor, etc can happen on different tickets.

Counter arguments:

https://uxmovement.com/buttons/why-you-shouldnt-gray-out-disabled-but The comments section of the main article provide a good teardown of using faded instead of greyed to represent inactive/disabled buttons.

Yep, I purposely included that link with the counter arguments. I don't really see any of those as that much of an issue. The main reason I think the Opacity is a good idea for Adapt is that it goes some way to make configuring in AAT easier, its only really a suggestion from a workflow perspective, balancing all of the issues we have - which is more complex from say a standard website.

The main issues appear to be:

• It doesn't solve for partially sighted or visually impaired users as the visual language is still ambiguous
• It doesn't solve the issue of the initial indistinction between an enabled and disabled button when either state is absent
• Greyed buttons are effectively, the standard
• There are other ways of overcoming the confusion of clicking a disabled button accidentally, rather than preventing a click initially
• Faded buttons don't solve the contrast issue

It seems that switching the visual metaphor for representing the disabled state between greyed and faded, retains mostly the same issues.

Yes, absolutely agree. I'm not sure its even solvable for all users. It will alway be a balance of requirements as requirements are often in conflict.

WCAG contrast requirements on inactive buttons:

https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html#inactive-controls While the section of the WCAG docs Understanding SC 1.4.11 does say that contrast accessibility requirements have been removed from inactive buttons, it does gives rationale as to why (that it's too difficult to provide a generic solution) and a future direction, both of which do not really support this proposal in spirit (the word inactive also has some contention).

I'm not sure I agree it doesn't support a future direction in spirit! As I say, this is very much a balance of considerations. Personally, I don't think adding an icon is a good solution, as it adds visual clutter, so again, we've fixing one thing and breaking another. So, really, all it comes down to is balancing the solution in a different way.

When we consider [aria-disabled] buttons as opposed to [disabled] buttons, the former are unclickable but focusable and readable, the latter are unclickable, unfocusable and unreadable. As such, the [aria-disabled] buttons will still need to be appropriately visible as an accessible UI component, as they are available to screen reader and keyboard accessible users. Meaning we probably should strive for good contrast on disabled buttons where possible.

Agree we should not [disabled] buttons. I also agree buttons need to be visible, I don't like the idea of hiding them. Personally, I think we'd have the same problems with contrast whether faded or greyed. Unless the greyed button is always contrasty regardless of branding, but then we have other issues.

Unavoidable downsides of faded/greyed:

https://medium.com/@h_locke/is-it-ok-to-grey-out-disabled-buttons-8afa74a0fae The references in this article discuss at length the different user groups impacted by disabled buttons (SR, various visual impairment, general axioms) and how the different solutions all have unavoidable downsides, mostly on the lines of:

• It doesn't solve for partially sighted or visually impaired users as the visual language is still ambiguous
• It doesn't solve the issue of the initial indistinction between an enabled and disabled button when either state is absent
• If a button isn't disabled it should instead display a warning

With specific reference to contrast on disabled buttons w3c/wcag21#805 and w3c/wcag#922 With specific reference to the Submit button being disabled before interaction fulfillment w3c/wcag#1512 for which we already have https://github.com/adaptlearning/adapt-contrib-instructionError

Yep, I like this plug-in, in someways this could be rolled in to Adapt.

There are a few suggestions the author has that we've not yet considered:

• Using the disabled mouse cursor on desktops on hover state for disabled buttons.
  
• Using recessing, or inner borders
• Inverting the text colour

I quite like adding the disabled mouse cursor.

Yep, as I say, opacity-ing the buttons doesn't seek to fix these specific issues. But, I don't like the idea of the cursor as its just a icon os ambiguous, its not really the right icon. A circle with a line though it indicates 'NO' as in no spoking etc. Plus more visual clutter. Personally, I'd rather not do this.

Disabling vs hiding:

Advantages of disabling:
Users always find the same control in the same place
Advantages of hiding:
Remove irrelevant items so users can focus on those relevant items, removing noise from the UI.

https://www.smashingmagazine.com/2021/08/frustrating-design-patterns-disabled-buttons/ This doesn't quite encapsulate the issue for me as the advantage and disadvantage seem more relevant for e-commerce sites, as can be seen in the above reference, where there can be many related and changing user interface components. In Adapt we very rarely have so many changeable controls.

Advantages of visible [aria-disabled] buttons:

• Object permanence, Object consistency
• Interaction affordances
• Keyboard and/or screen reader accessible
• Reduced cognitive load

When using a screen reader as a non-sighted user, UI changes, such as when buttons become shown or hidden or rearranged, are not alerted to the user. The unannounced introduction or removal of UI has the potential to disrupt a user's sense of object permanence and their orientation in the material, which introduces unnecessary cognitive load and potential confusion. This can be especially acute when hiding and introducing controls whilst navigating through a list of items.

Secondarily to object permanence, and this applies to sighted users as well, are the possible affordances to a user from an [aria-disabled] button. Narrative back buttons are always initially [aria-disabled], by having an [aria-disabled] back button and an enabled next button, it is possible to infer that; I am at the beginning of a list, I can't go back, I can go forward.

If the narrative back button were initially hidden, it would not be possible for the non-sighted screen reader user to infer that a back button should appear later, that a list is beginning or that the list must be navigated via next/back controls. None of those affordances would be immediately available but they would appear after the user had experienced the first content item, when the back button would be shown and later found. By hiding the back button in this use-case, we'd effectively be teaching the user about the user interface during the essential material and not, as is ideal, before it, where allowing them to learn the UI, then use it to navigate and focus on the content seems the most efficient use of time.

The case of the submit button is much the same as the narrative back button, in both regards. Having it readable+visible but disabled, signifies that it may become enabled. The instruction text, interaction description and UI all hint at the rules for its enablement.

Tooltips:

For best practise (not required by WCAG) to account for usability/accessibility issues, disabled buttons could have a tooltip explaining that its disabled and the reason for the disabled state. Although my feeling is, this could be optional on a project by project basis or not needed at all.

Which disabled buttons would they apply to? Which user-groups would this solve for?

Example:

Button Disabled tooltip
Submit Select x number of options and click submit to continue
Narrative back You cannot go backwards because you are at the beginning of the list
Locked menu This item is locked, please complete etc

Submit, form like buttons, I like the idea of having a tooltip, so its behaves like the 'instructionError plug-in only, it gives immediate feedback before having to press the button. I'm. to previous about this though. Just thought it was a nice feature.

• It doesn't solve for partially sighted or visually impaired users as the visual language is still ambiguous

For this reason, I think we shouldn't rely on colour alone (or opacity) to distinguish states (to be looked at as part of adaptlearning/adapt-contrib-core#386). For example, we could use the padlock icon for locked disabled buttons. Issue raised here for Tutor but a global approach to locked buttons in Adapt would make sense.

Agreed, we should definitely distinguish locked states with a padlock. PLP for example. Additionally, visited states are now represented with a tick (check mark) so we should make sure they are all aligned also.

• It doesn't solve the issue of the initial indistinction between an enabled and disabled button when either is absent

I'm in favour of disabling buttons rather than hiding.

• Greyed buttons are effectively, the standard

Although this is true, I think the initial issues raised around needing to theme to any branding/colour palette still needs addressing and many brands do include, clash or too similar to grey. I'd be in favour of having an opacity as a standard disabled state in Adapt. Whilst maintaining flexibility to support more complex styles for those brands where a disabled state is defined in brand guidelines (to be looked at as part of adaptlearning/adapt-contrib-core#386).

Agree. On balance, my feeling is moving over to opacity as standard is the best option currently. I'm not necessarily fixed on this but my feeling is, in production the first thing we'll do it switch from grey to opacity every project!

@kirsty-hames I like the option of being able to use opacity.

Opacity example:

There's a really good example highlighted in the reference w3c/wcag21#805 (comment) which links directly to the gov.uk disabled button spec https://govuk-elements.herokuapp.com/buttons/#button-disabled .

Gov.uk have only described the one "primary button" style here, with the distinct green etc. They are using disabled="disabled" though, which makes the button unclickable and unfocusable, and recommend an error message to explain why the button is disabled. So this has use-case ambiguity again, the error message cannot be associated with a button click as a button click isn't possible. But, they are definitely not recommending to hide the button.

• use the aria-disabled attribute for older screen readers

Gov.uk's point on using aria-disabled only for older screen readers is a bit wrong for us. So that it's possible to tab to a disabled button (keyboard a11y) and arrow to it (screen reader a11y) and so that it'll read as disabled in all scenarios (keyboard tab + screen reader) and display as disabled with styling, along with javascript to stop any click behaviour, we kind of use aria-disabled as described in this excerpt from mdn article on aria-disabled https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-disabled:

In fairness Gov.uk do go on to explain the two use-cases where they expect a disabled button might be used:

• an example of a useful disabled option is a calendar with greyed out days where no bookings are available
• provide another way for the user to continue, add an error message or text to explain why the button is disabled

Which is an unclickable list item with no children (calendar date with no booking, accordion item with no body, etc) and a continue button that requires further fulfillment (submit button on an mcq, locked menu button, etc).

Icons for disabled state:

For example, we could use the padlock icon for locked disabled buttons.

There are other mentions of using icons to indicate disabled states w3c/wcag21#805 (comment) . The "locked" state of plp, menu items and trickle are particularly good examples where there is a generic icon that represents why the button is disabled. Finding a similar uniform icon for the narrative back and question submit buttons might prove a little more difficult in the same way that trying to write tooltips for them is difficult.

Perhaps something similar to the disabled cursor icon may work?

Icons and tooltips:

Disabled button Disabled tooltip Disabled icon Note
Submit Select x number of options and click submit to continue ? Repeated instruction text which can be displayed with instructionError if necessary
Narrative back You cannot go backwards because you are at the beginning of the list ? Tooltip should read "Back" as it's an icon only button.
Locked menu/trickle/plp This item is locked, please complete etc Padlock Finding a specific tooltip text may prove a little difficult for menu items as locking requirements vary wildly but an icon should suffice. Trickle has aria text that could be used as a tooltip, but it will have an icon. Plp won't need a tooltip as the icon will be present along with the item text.
Generally I think using tooltips to display disabled state is a cumbersome idea that we shouldn't implement.

I actually thing tooltips is a great idea here and not cumbersome at all. Icons on the other hand are problematic, as its not clear what they would be, and also adds visual clutter. But as I say, not precious about this, and there is the option of doing this, if say a ba=rand requires it, no? Tooltips support disabled buttons? We're only talking about the default state?

Disabled buttons, existing use-cases and recommendations:

All disabled buttons should be aria-disabled=true not disabled="disabled" and have the class is-disabled. The attribute and class allows the button to be styled as disabled and to read in keyboard and screen reader accessibility.

We definitely have some use-cases for disabled buttons now:

• Locked

  • Visually disabled
  • Padlock icon and optional item text
  • Aria should prepend the Locked. globals equivalent to the item text, "unavailable" will be added by the screen reader

• List start/end (can be mixed with next locking)

  • Visually disabled
  • Left and right icon or back and next text
  • Aria should read "Back" or "Next" globals equivalent or otherwise the back and next text button text, "unavailable" will be added by the screen reader

• Form/question submit

  • Visually disabled
  • Submit text and an optional error reiterating the instructions
  • Aria should read the submit text, "unavailable" will be added by the screen reader

"Visually disabled" = greyed / faded, disabled mouse cursor

Current narrative back button:

Current submit button:

Nice!

I am in favour of the change but I see this change as part of a larger piece of work to organise buttons with Adapt.

Overview of thoughts:

• Categorise buttons in Adapt into sections and separate them out

  • navigation (nav bar / menu item) / question (submit / feedback / items) / ui (notify / drawer / component) etc

• Normalise styles through out Adapt to introduce consistency

  • Potential use of mixins for each category

• Retain a disabled style

  • Client branding often states specific disabled state styles (default can inherit static state)

• Add disabled button opacity support

Yep, agreed. I did want to get this through before bringing up other buttons as this is quite complex in itself, as seen from the discussion! :)

@StuartNicholls any thoughts?

I think we just need a pr for the opacity on buttons to resolve this issue? Could we keep greyed as the standard and supply opacity as an option?

I'd rather go with the opacity myself mainly because of the workflow and config issue (as WCAG isn't giving a steer and its permissible) so lets not try and guess what will happen here. But I will go with the consensus. I'd only say, if we went with grey default, the first thing we'd do is switch is over for every project!

The classes alignment (button type groupings), locked icons, disabled mouse cursor, etc can happen on different tickets.

Yep, agreed. Although I don't like the cursor idea. :)

So we're going with:

All disabled buttons should be aria-disabled=true not disabled="disabled" and have the class is-disabled.

• "Visually disabled" will be faded greyed by default, with the option for greyed faded
• The framework will still prevent the click action on aria-disabled buttons
• "unavailable" will be added by the screen reader because of the aria-disabled attribute

Disabled button types:

• Locked
  • Visually disabled
  • To contain a padlock icon and optional item text (padlock replaces icon on icon-only button)
  • Aria should have _globals._accessibility._ariaLabels.locked prepended to the item text
• List start/end (can be mixed with next locking)
  • Visually disabled
  • To contain a left and right icon or back and next text
  • Aria should read the "previous" or "next" globals equivalent for icon-only buttons or otherwise the back and next button text
• Form/question submit
  • Visually disabled
  • To contain submit text
  • Show a tooltip reiterating the instructions (to be created)
  • Aria should read the submit text

Where form/question submit buttons are not visually disabled:

• Show a notify reiterating the instructions

This sounds good to me. @guywillis / @kirsty-hames on board?

All disabled buttons should be aria-disabled=true not disabled="disabled" and have the class is-disabled.

• "Visually disabled" will be faded by default, with the option for greyed, facilitating AAT simplicity
• The framework will still prevent the click action on aria-disabled buttons
• Because of aria-disabled, "unavailable" will be added by the screen reader

Disabled button types:

• Locked

  • Visually disabled
  • To contain a padlock icon and optional item text (padlock replaces icon on icon-only button)
  • Aria should have _globals._accessibility._ariaLabels.locked prepended to the item text

• List start/end (can be mixed with next locking)

  • Visually disabled
  • To contain a left and right icon or back and next text
  • Aria should read the "previous" or "next" globals equivalent for icon-only buttons or otherwise the back and next button text

• Form/question submit

  • Visually disabled
  • To contain submit text
  • Show a tooltip reiterating the instructions (to be created)
  • Aria should read the submit text

Where form/question submit buttons are not visually disabled:

• Show a notify reiterating the instructions

--

This sounds good to me. @guywillis / @kirsty-hames on board?

I am 99% on board, yup.

My only comment would be that I would vote in favour of disabled buttons to be greyed over faded out as it's a 'safer' option. Disabled buttons can be displayed over a multitude of background colours and images within Adapt and having buttons with a solid background would be more defined and easier to distinguish in my mind.

It is, however, not a hill I will die on so if the general consensus is opacity I will go with it (providing the disabled button variables are still in place so that opacity can be switched off and the colour can be changed easily).

All disabled buttons should be aria-disabled=true not disabled="disabled" and have the class is-disabled.

• "Visually disabled" will be faded by default, with the option for greyed, facilitating AAT simplicity
• The framework will still prevent the click action on aria-disabled buttons
• Because of aria-disabled, "unavailable" will be added by the screen reader

Disabled button types:

• Locked

  • Visually disabled
  • To contain a padlock icon and optional item text (padlock replaces icon on icon-only button)
  • Aria should have _globals._accessibility._ariaLabels.locked prepended to the item text

• List start/end (can be mixed with next locking)

  • Visually disabled
  • To contain a left and right icon or back and next text
  • Aria should read the "previous" or "next" globals equivalent for icon-only buttons or otherwise the back and next button text

• Form/question submit

  • Visually disabled
  • To contain submit text
  • Show a tooltip reiterating the instructions (to be created)
  • Aria should read the submit text

Where form/question submit buttons are not visually disabled:

• Show a notify reiterating the instructions

--

This sounds good to me. @guywillis / @kirsty-hames on board?

I am 99% on board, yup.

My only comment would be that I would vote in favour of disabled buttons to be greyed over faded out as it's a 'safer' option. Disabled buttons can be displayed over a multitude of background colours and images within Adapt and having buttons with a solid background would be more defined and easier to distinguish in my mind.

It is, however, not a hill I will die on so if the general consensus is opacity I will go with it (providing the disabled button variables are still in place so that opacity can be switched off and the colour can be changed easily).

I agree to all proposed and echo Guy's thoughts here. I was initially on board with the opacity so I am doing a 180 here, but after having many projects in recent months with high accessibility requirements I agree we should make sure we provide sufficient contrast for disabled buttons and this is easily done with a solid colour rather than opacity. I think opacity is much cleaner and modern but could be problematic when applying background colours/images etc. As a default, I would be inclined to go with the safer option too, solid grey.

Side note to this, a bugbear for me is we also use grey for visited states. If we are sticking to grey as disabled I think the visited state should be changed. Issue raised in #470

Looks like we have consensus on the summary above. Amends will be required across various plugins so I've used the summary provided to create a checklist. Please edit, add links to issues/PRs as and when people pick tasks up.

Global disabled buttons

• All disabled buttons should be aria-disabled=true not disabled="disabled" and have the class is-disabled.
• "Visually disabled" will be faded greyed by default, with the option for greyed faded. The default is already grey, faded option to be added. Styles are inherited from .is-disabled class.
• The framework will still prevent the click action on aria-disabled buttons
• "unavailable" will be added by the screen reader because of the aria-disabled attribute

Disabled button types:

Locked

• Visually disabled. Styles are inherited from .is-locked class.
• To contain a padlock icon and optional item text (padlock replaces icon on icon-only button)
• Aria should have _globals._accessibility._ariaLabels.locked prepended to the item text

Buttons this applies to:

• Trickle button
• PR for disabled text New: Add option for disabled button text (fixes #207) adapt-contrib-trickle#214
• PR for padlock icon Update: padlock replaces icon when trickle button locked (#217) adapt-contrib-trickle#218
• PageLevelProgress items
• PR for padlock icon Update: display padlock for locked items (fixes #209) adapt-contrib-pageLevelProgress#210
• Boxmenu item button
• note, Boxmenu item already contains a 'status' icon which displays a padlock for locked state. Are we happy for this to remain as is instead of a button icon?
• PR for prepend locked ARIA to item button Update: prepend locked ARIA to item button (fixes #182) adapt-contrib-boxMenu#183

List start/end (can be mixed with next locking)

• Visually disabled. Styles are inherited from.is-disabled.
• To contain a left and right icon or back and next text
• Aria should read the "previous" or "next" globals equivalent for icon-only buttons or otherwise the back and next button text

Form/question submit

• Visually disabled
• To contain submit text
• Show a tooltip reiterating the instructions (to be created)
• Aria should read the submit text

Where form/question submit buttons are not visually disabled:

• Show a notify reiterating the instructions