Why not merge changes back into bootstrap itself?

[paypal]

Why not merge changes back into bootstrap itself?

[poorgeek]

👍 had the same thought myself

[vick08]

Thanks for asking. This is coming once we get the community play with the plugin and give us suggestions on improvements and refinements. We already received good feedback and are happy we didn’t rush with pull requests. HTH!

On Jan 30, 2014, at 3:17 PM, Justin Stockton [email protected] wrote:

had the same thought myself

—
Reply to this email directly or view it on GitHub.

[ddprrt]

👍 to @patrickhlauke request. Accessibility should be not an option but standard.

Great work, though! It's about time somebody takes care on that issue

[vick08]

Thanks. Point taken. :)

On Jan 31, 2014, at 2:02 AM, Stefan Baumgartner [email protected] wrote:

to @patrickhlauke request. Accessibility should be not an option but standard.

Great work, though! It's about time somebody takes care on that issue

—
Reply to this email directly or view it on GitHub.

[zacechola]

👍 for merging into core Bootstrap. I'm glad this project exists, though, so I'll be using it/providing feedback as is. Thanks!

[zacechola]

Looking through some of the styles, @mdo would not merge in some changes. Changing the .alert color contrast to simply use black would be immediately rejected. twbs 3.1 alert contrast currently meets WCAG 2.0 Level AA, but that took several tries before someone found a color combination the core team liked enough to merge in.

Here's the last change: twbs/bootstrap#11432 You can follow the references from there.

[vick08]

The large chunk of changes have to do with keyboard and ARIA support. I am sure we can reconcile the visual style differences.

On Feb 7, 2014, at 9:35 AM, Zac Echola [email protected] wrote:

Looking through some of the styles, @mdo would not merge in some changes. Changing the .alert color contrast to simply use black would be immediately rejected. twbs 3.1 alert contrast currently meets WCAG 2.0 Level AA, but that took several tries before someone found a color combination the core team liked enough to merge in.

Here's the last change: twbs/bootstrap#11432 You can follow the references from there.

—
Reply to this email directly or view it on GitHub.

[mdo]

We've always been on board with improving the accessibility features of Bootstrap. The biggest problem has been coordination and scope of changes. I have yet to dive into this more extensively, but we obviously welcome any and all practical improvements that can be made.

<3

[cvrebert]

Seems like a good chunk of this requires only simple changes to the static HTML in Bootstrap's docs (rather than invasive JS magic):

Selector	Add attribute
[data-toggle=dropdown]	aria-haspopup="true"
.modal-content	role="document"
[data-toggle="collapse"]	role="tab"
[data-slide="prev"] [data-slide="next"]	role="button"
.nav-tabs	role="tablist"
.nav-tabs > li	role="presentation"
.nav-tabs > [data-toggle="tab"] .nav-tabs > [data-toggle="pill"]	role="tab"

[superscott]

+1 for Merging.

[weboverhauls]

@cvrebert These roles are only needed when JS is running, therefore they should be added with the JS. For example, if they were added in the HTML, and a screen-reader user doesn't have access to JS, he/she will be very confused because the functionality described is missing.

[cvrebert]

@weboverhauls Bootstrap already pretty much assumes (at least for the widgets in question) that JS is running.

[patrickhlauke]

@weboverhauls I think that train already left the station a long time ago...devs adding roles directly to their HTML, and not generating it via JS, is a fairly common practice. I'd say any screenreader user without JS running is going to have a surprising/bad time nowadays on most sites.

[weboverhauls]

Sorry to hear that Patrick (and Chris). I thought you had a much higher appreciation for inclusive design and progress enhancement. Code quality is key. Please move this discussion to Twitter if you'd like.

[cvrebert]

I'm just stating the facts about how Bootstrap is currently architected, not any opinion on the merits of that architecture.

Please move this discussion to Twitter if you'd like.

No thanks. Intelligent discussions don't fit into 140 characters.

[zacechola]

I think it should be noted that WebAIM has studied the usage of JavaScript in screen readers and found the overwhelming majority have JavaScript enabled. Granted, this is a survey without a control group, so a big grain of salt. Similar results have been found in previous surveys, though.

[weboverhauls]

The screen reader example was just an obvious use case. The much bigger issue was outlined in a recent study in UK which showed that .9% of ALL users had JS enabled but didn't receive it. http://bit.ly/RTzBVk

[weboverhauls]

Code from the plugin continues to be ported into core, so closing issue.

[cvrebert]

Is the plugin's code going to be slimmed down accordingly, as things get ported into core?

[vick08]

The plugin is smart to overwrite the core features if we feel our implementation is better. In other words, we have been able to avoid conflicts so far.
On Oct 3, 2014, at 2:33 PM, Chris Rebert [email protected] wrote:

Is the plugin's code going to be slimmed down accordingly, as things get ported into core?

—
Reply to this email directly or view it on GitHub.

[weboverhauls]

I would like to see the plugin slimmed down.